Дело было так.  Одна маленькая организация государственных масштабов решила обновить во владении своем местном оборудование серверное. И обратились ее мужи к нашим доблестным менеджерам, мол, хотим мы серверов с дисками для сервисов наших важных. И узнали они от менеджеров о виртуализации заморской, отказоустойчивой да с кластеризацией.  Собственно, долго сказка сказывается, да быстро дело делается.  Так и появилась у организации той связка из двух серверов Fujitsu PRIMERGY RX 200 S8 и системы хранения данных ETERNUS DX 100 S3. И никто на тот момент не думал, что очень скоро ресурсов серверов тех не станет хватать. А наоборот, посчитали и были уверены, что хватит, и надолго. Но быстро машины виртуальные плодится стали и прожорливы они были да тучны. И тогда расширенно было пространство дисковое, а к двум RX 200 подселился брат их юный 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 выполнит ряд тестов безопасности и реализует запрос только если второй контроллер и зависимые компоненты работают штатно и целостности данных ничего не угрожает. Все логические диски, для которых отключенный контроллер являлся «владельцем», перейдут в обслуживание второго контроллера практически мгновенно и бесшовно после синхронизации кэша и смены путей передачи данных.  У линейки IBM (Lenovo) Storwize, например, данные манипуляции тоже проходят онлайн, но сами контроллеры выполняют цикл из нескольких поочередных перезагрузок после указания того, что это вовсе не ошибка и это мы добавили тот или иной компонент. И перезагрузки могут длиться, по показаниям системы, до 30 (!!!) минут каждая.  Хочется добавить еще несколько слов о реализованном здесь алгоритме безопасности, можно сказать, защите от необдуманных действий. А суть его проста и изящна: нельзя что-либо удалить нечаянным нажатием не туда, куда надо. Например, мы не можем удалить RAID-массив или логический диск пока не разберем всю цепочку взаимосвязей с самого «конца», а именно – сначала нужно изъять LUN-группы из настроек связи с хостом (Host Affinity), далее сами логические диски убрать из LUN-групп, удалить логические диски и только потом разрушить RAID. Согласитесь, сделать такое случайно и непреднамеренно практически невозможно.  Вкладки "Delete" LUN Group и RAID Group не активны до разрыва "связей" Стоит оговориться, что из командной строки (SSH) при  необходимости принудительное удаление любых элементов доступно сразу. Как уже упоминалось ранее, серверная часть кластера изначально состояла из 2-х серверов Fujitsu PRIMERGY RX200 S8, к которым в дальнейшем добавили аналогичное по классу и производительности устройство Fujitsu PRIMERGY RX 2530 M1. По сути, архитектурно устройства весьма схожи, но новая линейка процессоров Intel (как следствие и новые функции, инструкции, протоколы) в RX 2530 M1 сулила нам проблемы на уровне кластера VMware, а именно, проблемы с миграцией машин между хостами. Что и проявилось после внедрения: некоторые из уже имеющихся машин при миграции выдавали ошибку, связанную как раз с отличием CPU целевого сервера. Конечно же, VMware предусмотрела решение для подобного рода проблем, ее функция EVC (Enhanced vMotion Compatibility) предназначена для «маскировки» различий в процессорах разных поколений. Увы, изначально кластер поднимался на пятой версии виртуальной сферы VMware (VMware vSphere 5.5), которая тогда еще «понятия не имела» о новых процессорах Intel. Однако суть в том, что для нашей ситуации эта беда – вовсе не беда. Имея отказоустойчивый кластер, обновление до версии VMware vSphere 6.0 (EVC которой имеет возможность работать со всеми версиями процессоров) занимает всего нескольких часов. При правильном использовании и планировании кластера любой из имеющихся в нем серверов можно свободно обслуживать, распределив его машины на оставшихся хостах, используя «живую» миграцию. Миграция машины производилась со сменой не только хоста, но и хранилища данных, так как выполнялась реорганизация дискового пространства СХД. Данный процесс протекает путем полного клонирования машины, оригинал которой после синхронизации автоматически удаляется. Одновременная миграция (сервер и диск) возможна только при выключенной виртуальной машине. В VMware vSphere 5.5 поддержка процессоров заканчивается поколением "Sandy Bridge" В VMware vSphere 6.0 мы можем наблюдать "Ivy Bridge" и "Haswell" Подводя итог этой небольшой истории о кластерной виртуализации, хочется процитировать строчку из песни – «Летать с тобой мне было трудно, но без тебя я не могу дышать!». Ибо решиться на это трудно, да и дорого. Но зато потом страшно представить, как раньше без всего этого обходились, вспоминая потраченные выходные, обеды и ночи, нервы, переживания и надежду успеть завершить задуманное до конца перерыва или начала рабочего дня.  Подготовлено по материалу Третьякова Вячеслава, инженера компании «Парадигма». Полную версию статьи смотрите здесь.