Платформа для виртуализации 3(4) серверов + SAN

[Kabal]

Здравствуйте.
Есть на обслуживании компания, занимается продажей билетов (на аутсорсинге у нас).
Очень очень критично относятся к простоям - 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) Есть еще какие-то подводные камни на которые стоит обратить внимание? Пока ловлю себя на мысли что даже что спросить-то представляю с трудом

[gs]

Расскажите подробнее о нагрузках на сервера и бюджете.

[Kabal]

В принципе высокие мощности не требуются

исправил изначальную ошибку

точных цифр пока нет - конец рабочего дня, ответственного нет, но ни на одном сервере пока ничего критичного не наблюдается
помню веб - памяти занято 500 Мб, проц 0,1%, объем данных ~15 ГБ суммарно
ХР и УИС примерно настолько же загружены
БД съел 1,5 Гб РАМ и 350 Гб места.
в сезон отпусков возможно повышение нагрузки.
Количество IOps оценить не могу, не думаю что критично, но при необходимости сделаем.

В дальнейшем возможно привернуть сюда же еще пол десятка серверов (почтарь человек на 30 (SMTP), сервера AD, 1C, пока из них есть только почта). "Сюда же" - на ресурсы SAN, сервера докупятся. На данный момент задача - что-то сделать с системой продажи билетов

Бюджет: хорошо бы уложиться в $30.000.

[Ziggy Stardust]

Остальные какие-то старые, собранные непонятно из чего железки. В принципе высокие мощности не требуются, объем данных суммарно не превышает 1 Тб. Главное требование - постоянная доступность.

Высокая доступность - это подразумевает кластера. Кластера подразумевают SAN сеть более чем из двух серверов. SAN сеть более чем из двух серверов подразумевает хотя бы один (а лучше два) SAN свитча. А это уже за рамками бюджета получается... Т.е. придется в чем-то так или иначе ужиматься...

На текущий момент в качестве резервирования используются идентично настроенные машинки, выключенные из сети и от питания. (БД в случае краха будет заливать Москва через интернет). Однако это трудно считать высокой степенью отказоустойчивости.
Вот возникла идея реализовать решение с виртуализацией на базе пары серверов + SAN. Однако ни разу ни с SAN ни с виртуализацией выше уровня пары виртуалок поверх хостовой системы (не гипервизора) не имели.
Отсюда вопросы:
1) FC или iSCSI (в смысле хватит ли пропускной способности iSCSI чтоб грузить образы виртуалок)?

iSCSI в топку. С высокой доступность никак не вяжется. А чтобы началось вязаться придется в сетевое оборудование вложиться мама не балуйся как.
Два сервера с FC HBA можно без проблем напрямую подключить с резервированием каналов к двухконтрллерному FC внешнему стораджу.

2) BL или DL? Ориентируемся на решения HP и вроде как Blade сервера оптимальнее для виртуализации, но сколько ни прочел статей про блейды - плюсов кроме сниженного энергопотребления и количества проводов не нашел. Почему в итоге лучше - так и не понял. Но HP настаивает. Или на уровне до-10-серверов лучше с блейдами не заморачиваться?

Блейды становятся актуальными когда их у вас несколько стоек :-) Два лезвия в одном шасси точно не актуально. Опять же под блейды инфраструктура нужна серьезная, то же охлаждение хотя бы...

Под ваши текущие запросы будет вполне достаточно пары относительно мощных двухпроцовых супермикр, внешнего стораджа начального класса, вмвари для виртуализации. Собственно в 30к больше и не впихать :-)

Наш менеджер вам в почту пришлет примерные варианты.

[Kabal]

Высокая доступность - это подразумевает кластера. Кластера подразумевают SAN сеть более чем из двух серверов. SAN сеть более чем из двух серверов подразумевает хотя бы один (а лучше два) SAN свитча. А это уже за рамками бюджета получается... Т.е. придется в чем-то так или иначе ужиматься...

EMC Clariion AX4, например, (самый начальный SAN EMC) имеет 4 порта. Т.е. тут можно и без свичей 2 сервера подключить. Стоит правда как раз 30к. Бюджет можно несколько подвинуть, в разумных пределах, главное грамотно аргументировать.
В принципе-то даже 2 порта (по одному на сервер) уже неплохо (даже если 1 сервер выпадает, система работает). А потом и апгрейдить с темой виртуализации еще пары-тройки серверов. Сейчас не хочется экономить сильно, выбирая оборудование подешевле. Лучше по времени распределить закупки. Естественно ознакомив с рисками заказчика.
Думаю над вариантом докупить 1 сервер, а не 2, используя в качестве второго имеющуюся конфигурацию веб-сервера (ну не нужна такая мощь ему), что опять же высвобождает доп ресурсы для.. свичей? дополнительных HBA?

И спасибо! Жду предложений.

[Inna]

Kabal,

в почте вариант СХД и два варианта серверов. В бюджет укладываемся. =)

[Ziggy Stardust]

Только еще про лицензии на VMWare надо помнить.

[CrazyFrog]

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 соответвенно.

[Ziggy Stardust]

Бюджет 30к.

Не надо человеку навязывать авианосец, если ему вполне достаточно обычного моторного катера. :-)

http://vmware.com/partners/virtualize_o ... html?lr=54 - это касательно оракла и вмвари.

[CrazyFrog]

При чём тут морская тема? Автор не просто бесполезно потратиться, но и вполне вероятно сделает хуже чем было.

Сайт технической поддержки 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.

[Ziggy Stardust]

Итого.

На "взрослое" решение (кластера из рисковых серверов и т.п.) бюджета не хватает категорически.

Базу оракловую вынести на отдельные сервера, конечно было бы более правильным решением, чем запихивать ее в виртуалку. Тут согласен, но опять же бюджет :-)

Для виртуализации всей прочей кухни, которая была перечисленна и запланирована, имхо вмварь в самый раз.

Еще правда в голову приходит вариант перенести все сервисы на солярку и там по контейнерам разложить...

[hitower]

1) Веб. Вертится 3 сайта, один из них принимает запросы на резервирование билетов и передает далее по схеме. ОС FreeBSD.
2) это вообще рабочая станция с Win XP. Тут вертится одна программка, принимающая запрос с веб-сервера и передающая дальше. По всей видимости, преобразует данные в подходящий для УИС формат.
3) Сервер УИС. Эдакая система для преобразования данных с всяческих терминалов в данные БД и обратно. Несколько различных приложений.
4) БД Oracle.

Вы бы подумали немного об архитектуре софта. Только железом немногое получится сделать. По простому получится:
- 1) обеспечить отказоустойчивость веба. Зависит от софта, но как правило достаточно просто. Максимум у части людей придется начинать сеанс сначала при отказе одного из серверов.
- 4) отказоусточивость базы - standby, возможно RAC, тут у каждого свои предпочтения.

2) и 3) сильно зависят от того, на чем написан софт. под той же явой сделать отказоустойчивый кластер без общих компонент больших проблем нет.

[Kabal]

VMware тут не годится.

Виртуализация не защитит от сбоя приложения. Для этого необходим нормальный кластерный софт, с агентами, которые будут постоянно проверять работу прикладухи, чтобы если она сдохнет перезапустить её, перекинуть на другой узел и тп. vmware же может перезапустить только целиком ВМ, а на приложение внутри она реагировать не будет.

Ситуация осложняется тем что поддержку работы приложений (от веб до УИС) обеспечивает другая организация (удаленно из Москвы) и, практически, не идет на диалог. Нам туда лазить крайне не рекомендуется. В связи с чем весьма смутно представляю себе работу приложения и его архитектуру. Но от нас и не требуется - мы должны обеспечить отказоустойчивую площадку для работы этих приложений, за сбои внутри отвечает Москва. В схеме с виртуализацией вижу плюс в том что в случае сбоя на уровне ОС или приложения, можно будет в крайнем случае вручную погасить "сбитую" виртуалку чтобы автоматом поднялась идентичная рабочая. Это касается серверов 2 и 3. С Ораклом такой вариант, конечно, чреват, но всяко лучше имеющегося в плане времени простоя. А вообще именно сервер БД планируем реализовать на основе RHEL кластера, а не просто средствами HA вмвари. Также мусолю идею кластеризации и веба.

Так что для защиты от сбоев сервера нужен кластер, но он не может предотвратить нарушения целостности данных. Если у писюка произойдёт сбой в кеше процессора, то вполне вероятно искажение данных. Если на адаптере 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 соответвенно.

Один аргумент, уже озвученный - бюджет. Помимо стоимости оборудования есть еще проблема в отсутствии спецов по Sun, Solaris и виртуализации на этих платформах (и возможности хоть чему-то научиться).
По идее тогда надо еще территориально раскидать систему на случай пожаров и падений метеоритов. Но очевидно заказчику не требуется пока много-много девяток.

[Ziggy Stardust]

Очень очень критично относятся к простоям - 1 час = много потерянных денег.

Собственно из понимания "а сколько же именно будет потеряно денег" в результате часа простоя сервиса/ов и нужно исходить при проектировании отказоустойчивости и высокой доступности.

А то заочно и виртуально можно такого напроектировать, что и стартовая стоимость и дальнейшая совокупная стоимость владения на порядки стоимость всего бизнеса превысят :-))