Платформа для виртуализации 3(4) серверов + SAN
Модераторы: Trinity admin`s, Free-lance moderator`s
Платформа для виртуализации 3(4) серверов + SAN
Здравствуйте.
Есть на обслуживании компания, занимается продажей билетов (на аутсорсинге у нас).
Очень очень критично относятся к простоям - 1 час = много потерянных денег. Основным элементом в их инфраструктуре можно выделить 4 сервера:
1) Веб. Вертится 3 сайта, один из них принимает запросы на резервирование билетов и передает далее по схеме. ОС FreeBSD.
2) это вообще рабочая станция с Win XP. Тут вертится одна программка, принимающая запрос с веб-сервера и передающая дальше. По всей видимости, преобразует данные в подходящий для УИС формат.
3) Сервер УИС. Эдакая система для преобразования данных с всяческих терминалов в данные БД и обратно. Несколько различных приложений.
4) БД Oracle.
3 и 4 сервер на Red Hat Enterprise Linux.
Из всех четырёх только первый сервер относительно нов (HP ProLiant DL120, 8 ГБ оперативки). При этом средняя загрузка у него - менее 10% (гораздо менее).
Остальные какие-то старые, собранные непонятно из чего железки. В принципе высокие мощности не требуются, объем данных суммарно не превышает 1 Тб. Главное требование - постоянная доступность. На текущий момент в качестве резервирования используются идентично настроенные машинки, выключенные из сети и от питания. (БД в случае краха будет заливать Москва через интернет). Однако это трудно считать высокой степенью отказоустойчивости.
Вот возникла идея реализовать решение с виртуализацией на базе пары серверов + SAN. Однако ни разу ни с SAN ни с виртуализацией выше уровня пары виртуалок поверх хостовой системы (не гипервизора) не имели.
Отсюда вопросы:
1) FC или iSCSI (в смысле хватит ли пропускной способности iSCSI чтоб грузить образы виртуалок)?
2) BL или DL? Ориентируемся на решения HP и вроде как Blade сервера оптимальнее для виртуализации, но сколько ни прочел статей про блейды - плюсов кроме сниженного энергопотребления и количества проводов не нашел. Почему в итоге лучше - так и не понял. Но HP настаивает. Или на уровне до-10-серверов лучше с блейдами не заморачиваться?
3) Есть еще какие-то подводные камни на которые стоит обратить внимание? Пока ловлю себя на мысли что даже что спросить-то представляю с трудом
Есть на обслуживании компания, занимается продажей билетов (на аутсорсинге у нас).
Очень очень критично относятся к простоям - 1 час = много потерянных денег. Основным элементом в их инфраструктуре можно выделить 4 сервера:
1) Веб. Вертится 3 сайта, один из них принимает запросы на резервирование билетов и передает далее по схеме. ОС FreeBSD.
2) это вообще рабочая станция с Win XP. Тут вертится одна программка, принимающая запрос с веб-сервера и передающая дальше. По всей видимости, преобразует данные в подходящий для УИС формат.
3) Сервер УИС. Эдакая система для преобразования данных с всяческих терминалов в данные БД и обратно. Несколько различных приложений.
4) БД Oracle.
3 и 4 сервер на Red Hat Enterprise Linux.
Из всех четырёх только первый сервер относительно нов (HP ProLiant DL120, 8 ГБ оперативки). При этом средняя загрузка у него - менее 10% (гораздо менее).
Остальные какие-то старые, собранные непонятно из чего железки. В принципе высокие мощности не требуются, объем данных суммарно не превышает 1 Тб. Главное требование - постоянная доступность. На текущий момент в качестве резервирования используются идентично настроенные машинки, выключенные из сети и от питания. (БД в случае краха будет заливать Москва через интернет). Однако это трудно считать высокой степенью отказоустойчивости.
Вот возникла идея реализовать решение с виртуализацией на базе пары серверов + SAN. Однако ни разу ни с SAN ни с виртуализацией выше уровня пары виртуалок поверх хостовой системы (не гипервизора) не имели.
Отсюда вопросы:
1) FC или iSCSI (в смысле хватит ли пропускной способности iSCSI чтоб грузить образы виртуалок)?
2) BL или DL? Ориентируемся на решения HP и вроде как Blade сервера оптимальнее для виртуализации, но сколько ни прочел статей про блейды - плюсов кроме сниженного энергопотребления и количества проводов не нашел. Почему в итоге лучше - так и не понял. Но HP настаивает. Или на уровне до-10-серверов лучше с блейдами не заморачиваться?
3) Есть еще какие-то подводные камни на которые стоит обратить внимание? Пока ловлю себя на мысли что даже что спросить-то представляю с трудом
Последний раз редактировалось Kabal 05 апр 2010, 17:25, всего редактировалось 1 раз.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Расскажите подробнее о нагрузках на сервера и бюджете.
Re: Платформа для виртуализации 3(4) серверов + SAN
исправил изначальную ошибкуВ принципе высокие мощности не требуются
точных цифр пока нет - конец рабочего дня, ответственного нет, но ни на одном сервере пока ничего критичного не наблюдается
помню веб - памяти занято 500 Мб, проц 0,1%, объем данных ~15 ГБ суммарно
ХР и УИС примерно настолько же загружены
БД съел 1,5 Гб РАМ и 350 Гб места.
в сезон отпусков возможно повышение нагрузки.
Количество IOps оценить не могу, не думаю что критично, но при необходимости сделаем.
В дальнейшем возможно привернуть сюда же еще пол десятка серверов (почтарь человек на 30 (SMTP), сервера AD, 1C, пока из них есть только почта). "Сюда же" - на ресурсы SAN, сервера докупятся. На данный момент задача - что-то сделать с системой продажи билетов
Бюджет: хорошо бы уложиться в $30.000.
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Высокая доступность - это подразумевает кластера. Кластера подразумевают SAN сеть более чем из двух серверов. SAN сеть более чем из двух серверов подразумевает хотя бы один (а лучше два) SAN свитча. А это уже за рамками бюджета получается... Т.е. придется в чем-то так или иначе ужиматься...Kabal писал(а):Остальные какие-то старые, собранные непонятно из чего железки. В принципе высокие мощности не требуются, объем данных суммарно не превышает 1 Тб. Главное требование - постоянная доступность.
iSCSI в топку. С высокой доступность никак не вяжется. А чтобы началось вязаться придется в сетевое оборудование вложиться мама не балуйся как.На текущий момент в качестве резервирования используются идентично настроенные машинки, выключенные из сети и от питания. (БД в случае краха будет заливать Москва через интернет). Однако это трудно считать высокой степенью отказоустойчивости.
Вот возникла идея реализовать решение с виртуализацией на базе пары серверов + SAN. Однако ни разу ни с SAN ни с виртуализацией выше уровня пары виртуалок поверх хостовой системы (не гипервизора) не имели.
Отсюда вопросы:
1) FC или iSCSI (в смысле хватит ли пропускной способности iSCSI чтоб грузить образы виртуалок)?
Два сервера с FC HBA можно без проблем напрямую подключить с резервированием каналов к двухконтрллерному FC внешнему стораджу.
Блейды становятся актуальными когда их у вас несколько стоек :-) Два лезвия в одном шасси точно не актуально. Опять же под блейды инфраструктура нужна серьезная, то же охлаждение хотя бы...2) BL или DL? Ориентируемся на решения HP и вроде как Blade сервера оптимальнее для виртуализации, но сколько ни прочел статей про блейды - плюсов кроме сниженного энергопотребления и количества проводов не нашел. Почему в итоге лучше - так и не понял. Но HP настаивает. Или на уровне до-10-серверов лучше с блейдами не заморачиваться?
Под ваши текущие запросы будет вполне достаточно пары относительно мощных двухпроцовых супермикр, внешнего стораджа начального класса, вмвари для виртуализации. Собственно в 30к больше и не впихать :-)
Наш менеджер вам в почту пришлет примерные варианты.
С уважением, Александр
ICQ://13043204
ICQ://13043204
Re: Платформа для виртуализации 3(4) серверов + SAN
EMC Clariion AX4, например, (самый начальный SAN EMC) имеет 4 порта. Т.е. тут можно и без свичей 2 сервера подключить. Стоит правда как раз 30к. Бюджет можно несколько подвинуть, в разумных пределах, главное грамотно аргументировать.Ziggy Stardust писал(а): Высокая доступность - это подразумевает кластера. Кластера подразумевают SAN сеть более чем из двух серверов. SAN сеть более чем из двух серверов подразумевает хотя бы один (а лучше два) SAN свитча. А это уже за рамками бюджета получается... Т.е. придется в чем-то так или иначе ужиматься...
В принципе-то даже 2 порта (по одному на сервер) уже неплохо (даже если 1 сервер выпадает, система работает). А потом и апгрейдить с темой виртуализации еще пары-тройки серверов. Сейчас не хочется экономить сильно, выбирая оборудование подешевле. Лучше по времени распределить закупки. Естественно ознакомив с рисками заказчика.
Думаю над вариантом докупить 1 сервер, а не 2, используя в качестве второго имеющуюся конфигурацию веб-сервера (ну не нужна такая мощь ему), что опять же высвобождает доп ресурсы для.. свичей? дополнительных HBA?
И спасибо! Жду предложений.
- Inna
- Сотрудник Тринити
- Сообщения: 227
- Зарегистрирован: 01 ноя 2008, 11:03
- Откуда: Екатеринбург
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Kabal,
в почте вариант СХД и два варианта серверов. В бюджет укладываемся. =)
в почте вариант СХД и два варианта серверов. В бюджет укладываемся. =)
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Только еще про лицензии на VMWare надо помнить.
С уважением, Александр
ICQ://13043204
ICQ://13043204
Re: Платформа для виртуализации 3(4) серверов + SAN
VMware тут не годится.
Виртуализация не защитит от сбоя приложения. Для этого необходим нормальный кластерный софт, с агентами, которые будут постоянно проверять работу прикладухи, чтобы если она сдохнет перезапустить её, перекинуть на другой узел и тп. vmware же может перезапустить только целиком ВМ, а на приложение внутри она реагировать не будет.
Далее, Oracle на vmware не поддерживается. Из писюковой виртуализации Oracle поддерживается только с Oracle VM и Solaris zones.
Так что для защиты от сбоев сервера нужен кластер, но он не может предотвратить нарушения целостности данных. Если у писюка произойдёт сбой в кеше процессора, то вполне вероятно искажение данных. Если на адаптере I/O будет глючная фирмварь, то на диск будет записываться мусор вместо оракловых блоков.
Поэтому сервера должны быть RISC с их RAS, то есть чтобы чексуммы были от памяти до регистров процессора. А для защиты ораклового ввода-вывода система хранения должна поддерживать проверку оракловых блоков при записи -- технологию Oracle HARD (http://www.oracle.com/technology/deploy ... hardf.html).
Самая скромная конфигурация такого рода будет Sun M3000 + NetApp FAS2040 c Sun Cluster или IBM Power 520 + IBM N3600 с PowerHA. Для виртуализации на них можно использовать Solaris zones или LPAR/WPAR соответвенно.
Виртуализация не защитит от сбоя приложения. Для этого необходим нормальный кластерный софт, с агентами, которые будут постоянно проверять работу прикладухи, чтобы если она сдохнет перезапустить её, перекинуть на другой узел и тп. vmware же может перезапустить только целиком ВМ, а на приложение внутри она реагировать не будет.
Далее, Oracle на vmware не поддерживается. Из писюковой виртуализации Oracle поддерживается только с Oracle VM и Solaris zones.
Так что для защиты от сбоев сервера нужен кластер, но он не может предотвратить нарушения целостности данных. Если у писюка произойдёт сбой в кеше процессора, то вполне вероятно искажение данных. Если на адаптере I/O будет глючная фирмварь, то на диск будет записываться мусор вместо оракловых блоков.
Поэтому сервера должны быть RISC с их RAS, то есть чтобы чексуммы были от памяти до регистров процессора. А для защиты ораклового ввода-вывода система хранения должна поддерживать проверку оракловых блоков при записи -- технологию Oracle HARD (http://www.oracle.com/technology/deploy ... hardf.html).
Самая скромная конфигурация такого рода будет Sun M3000 + NetApp FAS2040 c Sun Cluster или IBM Power 520 + IBM N3600 с PowerHA. Для виртуализации на них можно использовать Solaris zones или LPAR/WPAR соответвенно.
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Бюджет 30к.
Не надо человеку навязывать авианосец, если ему вполне достаточно обычного моторного катера. :-)
http://vmware.com/partners/virtualize_o ... html?lr=54 - это касательно оракла и вмвари.
Не надо человеку навязывать авианосец, если ему вполне достаточно обычного моторного катера. :-)
http://vmware.com/partners/virtualize_o ... html?lr=54 - это касательно оракла и вмвари.
С уважением, Александр
ICQ://13043204
ICQ://13043204
Re: Платформа для виртуализации 3(4) серверов + SAN
При чём тут морская тема? Автор не просто бесполезно потратиться, но и вполне вероятно сделает хуже чем было.
Сайт технической поддержки oracle расположен по адресу metalink.oracle.com, а не vmware.com. И как раз на metalink есть документ 249212.1, в котором вполне лакончино написано
Сайт технической поддержки oracle расположен по адресу metalink.oracle.com, а не vmware.com. И как раз на metalink есть документ 249212.1, в котором вполне лакончино написано
Oracle has not certified any of its products on VMWare, and use of Oracle products in the RAC environment is also not supported.
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Итого.
На "взрослое" решение (кластера из рисковых серверов и т.п.) бюджета не хватает категорически.
Базу оракловую вынести на отдельные сервера, конечно было бы более правильным решением, чем запихивать ее в виртуалку. Тут согласен, но опять же бюджет :-)
Для виртуализации всей прочей кухни, которая была перечисленна и запланирована, имхо вмварь в самый раз.
Еще правда в голову приходит вариант перенести все сервисы на солярку и там по контейнерам разложить...
На "взрослое" решение (кластера из рисковых серверов и т.п.) бюджета не хватает категорически.
Базу оракловую вынести на отдельные сервера, конечно было бы более правильным решением, чем запихивать ее в виртуалку. Тут согласен, но опять же бюджет :-)
Для виртуализации всей прочей кухни, которая была перечисленна и запланирована, имхо вмварь в самый раз.
Еще правда в голову приходит вариант перенести все сервисы на солярку и там по контейнерам разложить...
С уважением, Александр
ICQ://13043204
ICQ://13043204
-
- Сотрудник Тринити
- Сообщения: 357
- Зарегистрирован: 23 дек 2007, 15:35
- Откуда: Москва
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Вы бы подумали немного об архитектуре софта. Только железом немногое получится сделать. По простому получится:Kabal писал(а): 1) Веб. Вертится 3 сайта, один из них принимает запросы на резервирование билетов и передает далее по схеме. ОС FreeBSD.
2) это вообще рабочая станция с Win XP. Тут вертится одна программка, принимающая запрос с веб-сервера и передающая дальше. По всей видимости, преобразует данные в подходящий для УИС формат.
3) Сервер УИС. Эдакая система для преобразования данных с всяческих терминалов в данные БД и обратно. Несколько различных приложений.
4) БД Oracle.
- 1) обеспечить отказоустойчивость веба. Зависит от софта, но как правило достаточно просто. Максимум у части людей придется начинать сеанс сначала при отказе одного из серверов.
- 4) отказоусточивость базы - standby, возможно RAC, тут у каждого свои предпочтения.
2) и 3) сильно зависят от того, на чем написан софт. под той же явой сделать отказоустойчивый кластер без общих компонент больших проблем нет.
Re: Платформа для виртуализации 3(4) серверов + SAN
Ситуация осложняется тем что поддержку работы приложений (от веб до УИС) обеспечивает другая организация (удаленно из Москвы) и, практически, не идет на диалог. Нам туда лазить крайне не рекомендуется. В связи с чем весьма смутно представляю себе работу приложения и его архитектуру. Но от нас и не требуется - мы должны обеспечить отказоустойчивую площадку для работы этих приложений, за сбои внутри отвечает Москва. В схеме с виртуализацией вижу плюс в том что в случае сбоя на уровне ОС или приложения, можно будет в крайнем случае вручную погасить "сбитую" виртуалку чтобы автоматом поднялась идентичная рабочая. Это касается серверов 2 и 3. С Ораклом такой вариант, конечно, чреват, но всяко лучше имеющегося в плане времени простоя. А вообще именно сервер БД планируем реализовать на основе RHEL кластера, а не просто средствами HA вмвари. Также мусолю идею кластеризации и веба.CrazyFrog писал(а):VMware тут не годится.
Виртуализация не защитит от сбоя приложения. Для этого необходим нормальный кластерный софт, с агентами, которые будут постоянно проверять работу прикладухи, чтобы если она сдохнет перезапустить её, перекинуть на другой узел и тп. vmware же может перезапустить только целиком ВМ, а на приложение внутри она реагировать не будет.
Так что для защиты от сбоев сервера нужен кластер, но он не может предотвратить нарушения целостности данных. Если у писюка произойдёт сбой в кеше процессора, то вполне вероятно искажение данных. Если на адаптере I/O будет глючная фирмварь, то на диск будет записываться мусор вместо оракловых блоков.
Один аргумент, уже озвученный - бюджет. Помимо стоимости оборудования есть еще проблема в отсутствии спецов по Sun, Solaris и виртуализации на этих платформах (и возможности хоть чему-то научиться).Поэтому сервера должны быть RISC с их RAS, то есть чтобы чексуммы были от памяти до регистров процессора. А для защиты ораклового ввода-вывода система хранения должна поддерживать проверку оракловых блоков при записи -- технологию Oracle HARD (http://www.oracle.com/technology/deploy ... hardf.html).
Самая скромная конфигурация такого рода будет Sun M3000 + NetApp FAS2040 c Sun Cluster или IBM Power 520 + IBM N3600 с PowerHA. Для виртуализации на них можно использовать Solaris zones или LPAR/WPAR соответвенно.
По идее тогда надо еще территориально раскидать систему на случай пожаров и падений метеоритов. Но очевидно заказчику не требуется пока много-много девяток.
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Платформа для виртуализации 3(4) серверов + SAN
Собственно из понимания "а сколько же именно будет потеряно денег" в результате часа простоя сервиса/ов и нужно исходить при проектировании отказоустойчивости и высокой доступности.Kabal писал(а):Очень очень критично относятся к простоям - 1 час = много потерянных денег.
А то заочно и виртуально можно такого напроектировать, что и стартовая стоимость и дальнейшая совокупная стоимость владения на порядки стоимость всего бизнеса превысят :-))
С уважением, Александр
ICQ://13043204
ICQ://13043204
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 22 гостя