Сказ о виртуализации – кластеризации и системе хранения данных Fujitsu
Дело было так.
Одна маленькая организация - государственных масштабов решила обновить во владении своем местном, оборудование серверное. И обратились ее мужи к нашим доблестным менеджерам, мол хотим мы серверов с дисками, для сервисов наших архиважных, да жарких. И узнали они от менеджеров наших о виртуализации заморской, с кластеризацией да отказоустойчивой.
Собственно, долго сказка сказывается, да быстро дело делается.
Так и появилась у организации той связка из двух серверов Fujitsu PRIMERGY RX200 S8 и системы хранения данных ETERNUS DX 100 S3. И никто на тот момент не думал, что очень скоро ресурсов серверов тех не хватать станет. А наоборот даже, посчитали и были уверены, что хватит и надолго. Но быстро машины виртуальные плодится стали и прожорливы они были да тучны. И тогда расширенно было пространство дисковое, а к двум RX200 подселился брат их юный Fujitsu PRIMERGY RX2530 M1.
О подселении нового сервера в кластер, а также о добавлении в контроллерные блоки новых карт расширения с дополнительными FC интерфейсами и поведать хочется. А вернее о простоте, безопасности и удобстве всех этих и других инженерных манипуляций, которые возможны (в нашем случае) с виртуализацией VMware и оборудованием Fujitsu. Те, кто уже имеет СХД и ту или иную реализацию виртуализации серверов (а возможно просто в теме) не удивятся и наверно не почерпнут ничего особо нового из этого текста. Но есть еще много организаций где какие-либо действия с оборудованием, его перезагрузкой и остановкой, вызывают ужас и заставляют скрупулезно планировать и минимизировать предстоящий downtime.
О системе хранения данных.
Как известно для того что бы добавить или убрать какой-либо компонент (не поддерживающий "горячую" замену) в уже работающем устройстве, предоставляющем сервисы и постоянно обменивающемся данными, его - устройство как правило требуется выключить. В случае с сервером его остановка неизбежна, в случаи с современными СХД, имеющими два контроллера все делается без остановок и пауз. Действительно помимо отказоустойчивости посредством многопутевого ввода-вывода (MultiPathing-а - где каждый из хостов (серверов) имеет по несколько каналов передачи данных от своих I/O портов к портам каждого из контроллеров СХД), современные системы хранения данных (в частности речь идет о Fujitsu ETERNUS DX 100 S3) умеют распределять/распараллеливать передачу данных по эти каналам уменьшая тем самым нагрузку и увеличивая пропускную способность, а время простоя при отказе одного из канало свести к нулю (active / active режим), либо минимизировать его при автоматическом переключении с активного (но "потерянного") канала, на пассивный – "ожидающий" (active / passive режим). Собственно, эти возможности, а также особенности операционной системы нам и позволяют вносить изменения в контроллерные блоки (либо заменять их полностью), без простоев и перезагрузок.
С DX 100 S3 это легко и просто выполняется следующим образом, отражающим всю безопасность и продуманность манипуляций.
Войдя в GUI под учетной записью сервисного инженера (f.ce) всю систему переводим в режим обслуживания.
-
-
Дале выбрав нужный нам контроллерный модуль переводим его в режим обслуживания.
-
-
Система перед вводом искомого блока в maintenance mod выполнит ряд тестов безопасности и реализует запрос только если второй контроллер и зависимые компоненты работают штатно и целостности данных ничего не угрожает. Все логические диски для которых отключенный контроллер являлся "владельцем" перейдут в обслуживание второго контроллера практически мгновенно и бесшовно, после синхронизации кэша и смены путей передачи данных.
В графическом интерфейсе станет видно, что контроллер больше не доступен и может быть извлечен. По окончанию манипуляций, так же в онлайн режиме возвращаем его на место, система автоматически, даже без перезагрузок самих контроллерных блоков все распознает и вернет прежнюю схему работы. Появившиеся новые устройства (у нас это FC адаптеры) нужно задействовать, добавив в систему. Вот и все, воистину у ETERNUS DX операционная система "реального времени".
(у линейки IBM (Lenovo) Storwize, например, данные манипуляции тоже проходят онлайн, но сами контроллеры выполняют цикл из нескольких поочередных перезагрузок после указания того что это вовсе не ошибка и это мы добавили тот или иной компонент и перезагрузки эти длится могут по заявлению системы до 30!!! минут каждая).
-
-
Хочется добавить еще несколько слов о реализованном здесь алгоритме безопасности, так сказать защите от необдуманных действий. А суть его проста и изящна, нельзя что-либо удалить нечаянным нажатием не там, где надо. Например, мы не можем удалить RAID массив или логический диск пока не разберем всю цепочку взаимосвязей с самого "конца", а именно - сначала нужно изъять LUN-группы из настроек связи с хостом (Host Affinity), далее сами логические диски убрать из LUN-групп, удалить логические диски и только потом разрушить RAID. Согласитесь, что сделать такое случайно и непреднамеренно практически невозможно.
-
Вкладки "Delete" LUN Group и RAID Group не активны до разрыва "связей".
-
Стоит оговорится что из командной строки (SSH) при необходимости принудительное удаление любых элементов доступно сразу.
-
О серверах и виртуализации.
Как уже упоминалось ранее серверная часть кластера состояла изначально из 2-х Fujitsu PRIMERGY RX200 S8, к которым в дальнейшем добавили аналогичное по классу и производительности устройство в виде Fujitsu PRIMERGY RX2530 M1. По сути, архитектурно устройства весьма схожи, но новая линейка процессоров Intel (а как следствие и новые функции, инструкции, протоколы) в RX2530 M1 сулила нам проблемы на уровне кластера VMware, а именно проблемы с миграцией машин между хостами. Что собственно и проявилось после внедрения, некоторые из уже имеющихся машин при миграции выдавали ошибку, связанную как раз с отличием CPU целевого сервера. Конечно же VMware, предусмотрела подобного рода проблемы, ее функция EVC (Enhanced vMotion Compatibility) как раз и предназначена для "маскировки" различий в процессорах разных поколений. Но увы изначально кластер подымался на пятой версии виртуальной сферы VMware (VMware vSphere 5.5), она тогда еще понятия не имела о новых процессорах Intel. И здесь как раз вся суть в том, что для нашей ситуации — эта беда, вовсе не беда. Имея отказоустойчивый кластер, обновление до версии VMware vSphere 6.0 (EVC которой имеет возможность работать со всеми версиями процессоров) дело нескольких часов, без отрыва так сказать от производства. При правильном использовании и планировании кластера, любой из имеющихся в нем серверов можно свободно обслуживать, распределив его машины на оставшихся хостах, используя "живую" миграцию.
-
Миграция машины производилась со сменой не только хоста, но и хранилища данных, так как выполнялась реорганизация дискового пространства СХД. Данный процесс протекает путем полного клонирования машины, оригинал которой после синхронизации автоматически удаляется. Одновременная миграция (сервер и диск) возможна только при выключенной виртуальной машине или из vSphere Web Client
-
В VMware vSphere 5.5 поддержка процессоров заканчивается поколением "Sandy Bridge"
-
В VMware vSphere 6.0 мы можем наблюдать "Ivy Bridge" и "Haswell"
-
Подводя итог, о кластерной виртуализации хочется процитировать строчку из одной песни – " Летать с тобой мне было трудно, но без тебя я не могу дышать!". Ибо решится на это трудно, да и дорого. Но зато потом страшно представить, как раньше без всего этого обходились, вспоминая потраченные выходные, обеды и ночи, нервы, переживания и надежду успеть завершить задуманное до конца перерыва или начала рабочего дня.