Что нам стоит облака построить

Cloud Computing. Наверное, тема уже немного избита. Если бы мы говорили о моде, то лучшие кутюрье нашей отрасли назвали бы это трендом 2011 года. И хотя сам термин появился достаточно давно, особую популярность он получил именно в этом году. Раньше было приятно только думать об облаках, пробовать их «на вкус», не вникая в глубины, и мечтать, что когда-то и у меня будет возможность прикоснуться к воздушным технологиям…

Не стоит блистать тут терминологией и раскладывать облака на внутренние и внешние, частные и глобальные – об этом написано не раз. В этой статье хотелось бы раскрыть, как именно я понимаю термин «облако».
С течением времени я понял, что мне гораздо легче писать о чем-то конкретном, что я уже потрогал руками, что перестало быть для меня черным ящиком. Жизнь пока не дала мне возможности прикоснуться к глобальным облакам, то есть как раз прикоснуться-то  можно: есть Google, вот-вот стартует сервис Icloud от Apple. С потребительской точки зрения мы летаем в облаках давно. Но вот создать или хотя бы поучаствовать в создании глобального сервиса, которым будут пользоваться миллионы, еще не довелось. Потому и говорить мы сегодня будем о маленьком частном облаке, а точнее – о технологиях виртуализации.

Прошу не рассматривать данную статью как рекламу какого-либо решения. То, что для реализации нашего проекта виртуализации мы выбрали продукт от VMware, вовсе не означает, что он лучше или хуже других. У каждого решения, будь то Microsoft, Xen или любой другой не менее уважаемый производитель, есть свои плюсы и удобные функции, однако ни одно из них пока не совершенно.

Начало

Как ни странно, мое первое знакомство с технологиями виртуализации произошло не в серверной комнате, когда я, содрогаясь от нетерпения, устанавливал первый Hypervisor на тестовый сервер, а в Германии, куда  вместе с коллегами по клубу ИТ-директоров был приглашен компаний PC-Ware. Один из докладов был посвящен решениям VMware, и надо отдать должное докладчику, рассказ оказался очень интересным и познавательным. Несмотря на то, что речь в нем шла о сугубо технических вещах, именно тогда я внутри себя уяснил, что же такое облако. Чем отличается несколько виртуализованных серверов, объединенных размещением в одной серверной комнате, от настоящего облака.
По моему мнению, облаком можно назвать серверную инфраструктуру, где сервис или платформа по-настоящему отвязаны от железа, на котором они запущены. И чем меньше мы знаем о том, на каком именно железе «крутится» наш сервис, тем «облачнее» будет данное решение. Качественной настройкой такой инфраструктуры послужит такая, после которой системный администратор при публикации сервиса не будет больше оперировать такими понятиями, как сервер или лезвие, а просто, выражаясь красиво, запустит сервис в облако. А уже сама инфраструктура, максимально в автоматическом режиме, распорядится доступными мощностями для размещения сервиса и обеспечения его отказоустойчивости.

Первые шаги

Мне повезло, впрочем, как везло всегда в этом вопросе: при вступлении в должность досталась инфраструктура, где за все отвечал всего лишь один маленький сервер, ничем не отличающийся от стандартного рабочего ПК. Всегда приятно начинать с самого начала, поэтому и закупка серверов велась уже с учетом того, что впоследствии они будут виртуализованы.

Итак, мы разделили серверы условно на два типа: помощнее (процессоры XEON) и попроще (процессоры Core2Duo). В остальном они были примерно одинаковы. Инфраструктура росла, основные сервисы настроены и начали предоставляться, пора было переходить к активным действиям. Мы приобрели дополнительный сервер (из тех, что «помощнее») и установили на него HyperVisor. На тот момент это был ESxi 4.0. Идея достаточно проста: после тестирования на первый сервер перетаскиваем сервисы с основных серверов, начиная с менее критичных, затем освобожденные серверы тоже виртуализуем, чтобы перетащить на них оставшиеся сервисы. В планах было сделать все операции, не растягивая надолго сам процесс, то есть примерно за полтора-два месяца.

Сложности перехода

Тестовый сервер мы приобретали сразу с дисковой подсистемой, которая легко поддерживается VMware. То есть при установке мы увидели хранилище, а это был массив Raid 5, организованный с помощью Adaptec-адаптера. На сайте VMware есть список поддерживаемых устройств хранения. Так вот в этот список не входит ни один встроенный Raid-контроллер, наиболее часто используемый в современных сереверах начального уровня. Естественно, когда мы подошли к виртуализации второго лезвия, предварительно перетащив с него сервис доступа в сеть (Firewall), стало понятно, что его дисковая подсистема не подерживается EsXi в режиме Raid-массива, и, как мы ни пытались, видно было три отдельных диска. Соответственно, второе лезвие, а вслед за ним и третье, с таким же контроллером, не имело на данный момент отказоустойчивой дисковой подсистемы. Это привносило здоровый риск в работу инфраструктуры, но все-таки с этим можно было мириться, настроив дополнительные Backup для виртуальных машин, запущенных на этих серверах.

Когда все маленькие машинки были виртуализованы (контроллер домена, телефонная станция, сервер доступа, вспомогательный контроллер домена и файл сервера), пришло время основных серверов. Достаточно трудный в настройке сервер сертификатов CryptoPro и по совместительству Web-сервер был первым среди сложных. Если все предыдущие серверы переносились с полной инсталляцией, а для некоторых (firewall) был выбран режим полного виртального приложения, то для Web-сервера, чтобы избежать повторной инсталляции системы, мы решили попробовать режим конвертации. Достаточно удобная функция, называемая wmware converter: с живой работающей машины снимается виртуальная копия, которую можно разместить на виртуальной площадке. В итоге простой сервиса не превышает 10 минут (время, необходимое на старт сервера внутри виртуальной машины). Окрыленные успехом, перенесли таким способом сервер СКУД. На самом деле это не сервер, а обычная машинка под управлением Windows XP с установленной программой общения с контроллерами системы доступа посредством ComPort.

Два или три дня все шло нормально. То ли сервисы не слишком популярные, то ли ресурсов для их работы требуется немного, но проблему мы заметили не сразу. И только с течением времени стало понятно, что использовать эти виртуальные машины нельзя. Скорость работы после переноса резко снизилась, у Web-сервера наблюдались резкие торможения при загрузке страниц документооборота. Сервер СКУД иногда просто был недоступен. Пришлось инсталлировать системы заново в другие машины и последовательно переносить сервисы на новые платформы. Отсюда вывод: конвертацию можно использовать только для обесепечения минимального времени простоя сервиса, в дальнейшем от конвертированных машин необходимо избавиться, и чем скорее, тем лучше.

Vcenter

Конечно, для целей установки и настройки виртуальных машин достаточно VMWare Vsphere Client. Он и к консоли даст возможность подключиться, и все простейшие действия совершить. Но по-настоящему удобным для настройки и управления своей виртуальной инфраструктурой инструментом станет для вас Vcenter –  отдельная виртуальная машина с установленным дистрибутивом Vcenter. Кстати, до покупки лицензии (а она совсем недешева) можно использовать его почти в полной функциональности 60 дней ознакомительного периода. По окончании, если закупка лицензий по каким-то причинам не произошла, всю виртуальную машину необходимо переустановить и залить конфигурацию Vcenter заново.

Серверы баз данных

Без виртуализации оставались серверы баз данных «1С», учетные программы, «Интермех», конструкторская и технологическая подготовка и почтовый сервер. Если первые располагались на высокоскоростном хранилище, сдерживающим фактором опять являлось то, что адаптер, на котором был выполнен Raid-массив, не входил в список поддерживаемых VMware устройств. Последний же имел настолько внушительную базу писем, что копировать ее хотелось только один раз. А для того, чтобы копировать ее только один раз, необходима система хранения данных. Вообще говоря, СХД необходима, конечно, не для этого. Без нее невозможны такие сервисы, как vMotion или HA Failover Clusters, но о них чуть позже. Просто необходимость установки СХД уже была понятна, и мы приняли решение отложить виртуализацию почтового сервера до окончания конкурса на закупку.
Как же обеспечить минимальное время простоя сервисов «1С», если даже Raid придется заново пересобирать на адаптере, понятном для VMware? Конвертация в данном случае не поможет – Windows не стартует на сервере с отличным от своего Raid-контроллером. К сожалению, на нашем сервере баз данных система была установлена на раздел, созданный на RAID-массиве. Ответ прост: нужен близнец.

В виртуальной среде мы создали машину под управлением Windows server 2008 R2. Кстати, удобство лицензии Windows Server 2008 Enterprise edition заключается в том, что она позволяет устанавливать до четырех виртуальных машин без нарушения условий. Единственное ограничение –  все четыре машины должны располагаться на одном физическом хосте. На вновь созданной платформе мы подняли все необходимые сервисы для поддержки «1С», сервер SQL (хватит и Express edition, если базы у вас небольшого размера) и «1С»-сервер предприятия. Дело за малым – для перехода на временный сервер, то есть на близнеца, достаточно:
• Остановить доступ к основному серверу.
• Скопировать базы данных на близнеца.
• Зарегистрировать все базы данных на «1С»-сервере предприятия.
• Остановить старый сервер.
• На DNS-сервере прописать Alias для близнеца с именем старого сервера.
• Переставить ключ сервера предприятия.
• Проверить доступность баз.

Таким образом мы обеспечили себе достаточно времени, чтобы спокойно заняться заменой Raid-адаптера, сборкой нового массива, включением этого сервера в уже созданный кластер.

Система хранения данных

В принципе нельзя считать, что мы купили ее слишком поздно. Вроде все вовремя. Точно определилось конечное число хостов. Внутренние хранилища возможно использовать под Backup или просто хранить на них что-нибудь ненужное. Если это были стандартные SATA-диски, то их просто можно вынуть и использовать по назначению для десктопов пользователей. И все-таки, оглядываясь назад, можно с увереностью сказать: устанавливать СХД «удобнее» сначала. Просто достаточно трудно уместить ее в своих бюджетах и доказать необходимость ее закупки руководству. Но гораздо удобнее виртуализировать платформы с уже подключенной системой хранения, не перенося потом виртуальные машины с локальных хранилищ на datastore. Хотя и наш путь неплох. Сервисы виртуализации, которые невозможно запустить без единого хранилища, прекрасный довод в пользу ее закупки. А в нашем случае пройти три четверти пути и не дойти до конца – уже не представлялось возможным.

Не буду подробно останавливаться на конфигурации хранилища, а ниже, в советах, постараюсь обобщить, на что необходимо обратить внимание. Сразу отмечу, что у нас возникли проблемы с установкой HBA-адаптеров. Мало того что они требуют дополнительных драйверов, так еще и не все серверы, особенно те, что выполнены в 1-unit-исполнении, имели свободные слоты для установки. Обычно это касается сервера – машрутизаторов, в которых три и более сетевых адаптеров. Выходом для нас стала установка машрутизатора отдельно, вне виртуальной инфраструктуры, что в принципе нормально для решения VIPnet, с помощью которого мы обеспечили защиту выделенных каналов. Чтобы установить драйверы HBA-адаптера на ESXI, потребовалось создание виртуальной машины vSphere Management Assistant, vMA (готовая скачивается с сайта vmware.com.).

После подключения всех серверов к хранилищу мы приступили к созданию LUN. Конфигурация нашей СХД включает в себя два LUN, быстрый, созданный на жестких дисках SAS, и медленный, расположенный на дисках SATA и соотвественно менее быстрый. Более быстрое хранилище мы используем для хранения всех баз данных, есть возможность для запуска самих ESXi. На медленном LUN располагаются все backup-версии виртальных машин, Transaction log всех SQL баз данных, которые, кстати, имеют наиболее внушительный размер, а к скорости доступа совсем не  взыскательны.

Запуск в облако

Установка и подключение СХД, а также настройка LUN и Vcenter наконец дали нам возможность использования таких сервисов, как vMotion и HA. В принципе это то, к чему мы стремились. Но давайте по порядку.
Благодаря vMotion появилась возможность легко остановить физический сервер и добавить, к примеру, оперативной памяти, не останавливая при этом никаких сервисов. Просто для остановки физического сервера все виртуальные машины перемещаем на другие хосты и производим необходимые работы.
Но главной целью все равно остается HA Failover Clusters, дословно «отказоустойчивый кластер высокой доступности». Именно за счет него мы смогли создать полностью отказоустойчиваю структуру, при которой уже обеспечивается защита от выхода из строя физических серверов. Для его настройки создали два кластера – в соответствии с типами серверов, которые купили (на процессорах XEON и Core2Duo), в каждом кластере включили этот сервис. Теперь при отказе хоста все виртуальные машины автоматиченски будут запускаться на другом хосте кластера, менее загруженном или специально предназанченном для данной виртуальной машины. Особенностью такого решения будет необходимость предусмотреть достаточное колличество ресурсов (как правило, достаточное колличество оперативной памяти) для запуска избыточного количества виртуальных машин. В настройке HA есть автоматический контроль ресурсов кластера в трех вариантах:
•    Зарезирвировать целый хост или несколько хостов (удобно в крупных сетях).
•    Зарезервировать в процентах от общего количества ресурсов.
•    В виде сокетов ресурсов.

В нашем случае мы решили использовать резервирование в размере 25% от общей загрузки кластера.
Еще одна проблема, с которой сталкивается каждый устремившийся в облака специалист. При создании HA Failover Clusters USB-ключи, «проброшенные» в виртуальные машины при выходе из строя физического сервера и миграции машины на другой хост, станут недоступны, так как привязаны к конкретному физическому хосту, попросту вставлены в него. Решение подсказала сама VMWare, вернее, один из участников форума на сайте этой компании. USB HUB AnywhereUSB фирмы Digi, предназначенный для передачи доступа к USB-устройствам в сеть. Устройство настраивается на фиксированный адрес в сети и доступ к ключам защиты, а именно к ним и была необходимость обеспечить доступ (прописывается в каждой виртуальной машине). Настройка достаточно гибкая, можно создавать группы портов и переадресовывать их определенным виртуальным машинам. При миграции машины на новый хост доступ к USB-ключам не прекращается, так как не привязан ни к какому физическому устройству облака.

Тесты

Конечно, после полной настройки хочется попробовать. Тест очень прост: взять и выключить питание одного из лезвий и посмотреть, когда и что запустится. Наш тест показал успешный автоматический запуск виртуальной машины на другом хосте кластера, но на запущенной машине не заработал сервер лицензий нормативной базы для конструкторов. Пока разбирались, выяснилось, что ключ USB для сервера лицензий воткнут в физический хост и с отключением питания перестал быть виден на мигрировавшей машине. Потеряшку извлекли и установили в USB Hub. Пока тестировали, нашли вариант, при котором HA не сработает. Если у физического хоста сгорит сетевой адаптер, но сам хост будет запущен и продолжит блокировать файлы виртуальной машины на СХД, виртуальная машина мигрировать не сможет. То есть Vcenter видит отсутствие хоста и пытается мигрировать оттуда приложения, в то время как файлы виртуальной машины заблокированы для использования другими физическими хостами. В этом случае точно требуется вмешательство обслуживающего персонала. И хотя это очень редкая ситуация, ее тоже можно обойти, зарезервировав сетевые подключения.
В остальном наша инфраструктура уже достаточно длительное время показывает себя нормальным, абсолютно отказоустойчивым решением, очень похожим на настоящее частное виртуальное облако. Сейчас на очереди настройки «катастрофоустойчивости» и донастройка другого облака на втором предприятии.

===========================================
Советы устремившимся в облака

1.    В штате должен быть специалист, владеющий вопросами виртуализации на профессиональном уровне. Обучите своих системных администраторов или наймите нового сотрудника. Аутсорсинг в этом вопросе я бы не советовал – слишком велика ответственность. Многие из ваших облачных сервисов критичны для бизнеса.
2.    Если вы точно уверены в количестве хостов и количестве сервисов, запланируйте закупку СХД сразу, в момент планирования инфраструктуры.
3.    Используйте лицензии Enterprice edition для серверных решений Microsoft, это позволит значительно сэкономить на лицензировании и развяжет вам руки при переходе.
4.    Используйте конвертацию при быстром переходе и отказывайтесь от конвертированных платформ как можно скорее. Старайтесь не применять конвертацию для критичных сервисов, лучше  используйте для них «близнецов».
5.    Внимательно проработайте структуру СХД – она должна быть максимально отказоустойчива! И по питанию, и по каналам связи, и по дисковым подсистемам. Проследите за наличием альтернавных источников питания не только для СХД, но и для коммутаторов, через которые она подключена к серверам. Сами коммутаторы тоже должны иметь резерв.
6.    Размещайте данные согласно скорости доступа к ним. В любом сервисе есть данные, критичные к скорости доступа, и данные, для которых не имеет значения, как быстро их можно прочитать.
7.    Используйте USB Hub для доставки USB-устройств до виртуальных машин. Не используйте USB-порты физических хостов, это противоречит принципам отказоустойчивости.