Опыт проектов виртуализации

Решил поделиться с читателями неким обобщенным опытом, касаемо проектов виртуализации (и не только), снабдив их небольшими байками по теме. Заранее хочу подчеркнуть, что все истории выдуманы, и любое совпадение с реальными персонажами и ситуациями из жизни - чистая случайность.

1) Выбирайте оборудование и ПО, исходя из ваших потребностей.

Часто можно столкнуться с такими перегибами. Клиент покупает полную корзину блейд-серверов с двумя управляющими модулями, ethernet и FC коммутаторами для отказоустойчивости, но при этом "забывает" купить несколько FC кабелей, или же банально не хватает PDU с какими-нибудь розетками типа IEC320 C19 для подключения всех блоков питания, а после подключения, оказывается, что ИБП не тянут.

Или же клиент берет три четырехсокетных сервера, покупает по 4-ре лицензии vSphere Enterprise Plus и Windows Server Datacenter на каждый сервер, хотя никакой функционал Enterprise Plus использовать не планирует, да и виртуальных машин у него всего ~10 на весь кластер. А иногда, бывает, и по одной ВМ на сервер хочет оставить, чтобы "надежнее" и "производительнее".

2) "У нас мало денег, возможно, мы даже не сможем вам заплатить."

Это противоположная крайность (я о ней писал). У инженеров будет прекрасная возможность научиться работать с консолью Windows Server Core, а также научиться подключаться MMC оснасткой Hyper-V Manager с недоменных компьютеров.

Еще пример: раньше у заказчика были 2 сервера с 6-тью 18 ГБ SCSI жесткими дисками, а теперь стал один с 4-мя ВМ на нескольких 1 ТБ SATA дисках. Все работает и не тормозит... почти.

3) Смотреть HCL нужно до покупки оборудования.

Об этом случае я тоже рассказывал. Клиент купил FC библиотеку, надо бы подключить к серверу резервного копирования. А он, оказывается, в ВМ на VMware.

4) Не все, что работает - поддерживается, не все, что поддерживается - работает.

У заказчика на виртуальном сервере один из разделов зашифрован с помощью Secret Disk. Для работы данного ПО требуется USB ключ защиты Aladdin, который предусмотрительно "проброшен" в ВМ с помощью соответствующей функции (даже галочка для поддержки работы с vMotion стоит). Требуется перенести диски ВМ с одного хранилища на другое без простоя. Нам поможет Storage vMotion. Алле-оп! USB ключ после переноса остается, Secret Disk отваливается из-за его отсутствия.

5) Это не баг, это фича/by design.

Например, совсем недавно столкнулся с особенностями работы блейд-коммутаторов Brocade, которые после собственной перезагрузки не отображают WWN HBA серверов, на которых установлен VMware ESXi. И чтобы это исправить, нужно сами серверы перезагрузить.

6) Середина проекта - отличный способ начать всё сначала.

Проект по внедрению виртуализации на базе Microsoft Hyper-V. Все машины развернуты, AD поднята, Exchange установлен, почтовые ящики смигрированы, файловые папки перетащены. В какой-то момент выясняется, что Failover Cluster просто не отрабатывает (это не камень в огород Microsoft, просто так было). Недолгая переписка с поддержкой результатов не дала, а сроки и так были сорваны. Волевое решение - переход на VMware ESX. Два выходных дня и все виртуальные машины сконвертированы. А дизайн-проект и прочую документацию всегда можно переписать.

7) Нет ничего более постоянного, чем временное.

Предположим, вы с коллегой монтируете сервер и подключаете его разными кабелями:

(Вы): -Давай прикрутим этот прекрасный HP Cable Management Arm?
(Он): -Ой, так ломает, тут такая путаница в проводах, давай, я чуть попозже прикручу.
(прошло 2 месяца...)

Поэтому, например, чем дольше идет проект, тем меньше шансов обновить firmware для СХД или для одного из серверов.

8) Бумажка с паролями.

Мало у кого из клиентов инфраструктура подробно документирована. Часто он и сам не знает, что-какой сервер делает, особенно если предыдущий администратор уволился и толком дела никому не передал.

Нередки случаи, когда "базы у нас хранятся вот на этой СХД, но пароля от нее я не помню".

Или, например, клиент отказывается от покупки почтового антивируса, мотивируя тем, что у него уже есть необходимые лицензии. Проект начинается, и оказывается, что лицензии на антивирус есть, но только на файловый антивирус на клиентские компьютеры.

9) Приёмо-сдаточные испытания - прекрасный способ еще раз "обработать напильником".

Наверняка все так или иначе с этим сталкивались. Заказчик принимает систему, инженер исполнителя проверяет чек-лист, выполняя заранее описанные действия, и демонстрируя ожидаемый результат, вроде: "Проверить журнал событий и убедиться в отсутствии ошибок... Так, проверяем... ошибок не... есть." Дальше следует разбор полетов с судорожной попыткой инженера если уж не решить проблему, то придумать правдивую отмазку. Самый тяжелый случай был, когда в результате запуска и проверки работы одного из бизнес-приложений, описанного в требованиях в ТЗ, сервер просто уходил в перезагрузку... на глазах у заказчика.

10) Законы Мёрфи работают.

Пару раз были случаи, когда система ломалась или серверы зависали на следующий день (в одном из проектов буквально), после приёмо-сдаточных испытаний и подписания акта выполненных работ.

Купил один клиент MSA 2000i с двумя контроллерами, каждый к своему коммутатору подключен, оба блока питания запитаны от двух разных ИБП. Отдельный диск под hot spare. Сломалась эта MSA. Просто так.