Миграция между независимыми аппаратными конфигурациями

diz решил поделиться своим опытом бесшовной замены оборудования при ограниченных аппаратных ресурсах – отсутствии SAN-коммутаторов и двух хранилищах.

В нашем предприятии уже несколько лет используется виртуальная инфраструктура. Как обычно бывает,  все началось с песочницы на базе VMware Server и нескольких тестовых виртуальных машин, часть которых потребовалось перевести в продуктив, а выделять к существующим двум десяткам физических серверов, большей частью самосборных и\или устаревших, еще несколько – не было средств. В результате было принято решение произвести модернизацию двух существующих серверов, перейти на VMware ESXi и за счет этого увеличить степень консолидации виртуальных машин. Результат от модернизации (установка аппаратного RAID-контроллера с BBU, увеличение количества дисков с 2 до 6 в RAID10, увеличение оперативной памяти до 8 ГБ) превзошел все ожидания: степень консолидации значительно возросла. Неприятным «бонусом» стал риск массовой недоступности сервисов в сценарии аппаратного выхода из строя одного из серверов. Путём долгих обоснований и мучений была приобретена двухконтроллерная СХД IBM DS3400 и осуществлена миграция на нее, совмещенная с еще одним этапом модернизации всё тех же серверов. Процедура миграции описана Mister Nobody: «Миграция с ESX 3.5i на vSphere». В итоге была получена следующая схема инфраструктуры (на самом деле, было два сервера на платформе Intel SR2520 и один IBM x3650, но к Intel не удалось найти стенсилы 🙂 :Два продуктивных сервера были подключены к СХД в HA кластер VMware, третий – сервер-песочница, был подключен к vCenter, но его виртуальные машины размещались на локальном datastore. Такая схема, с одной стороны, позволила обойтись без дорогих SAN-коммутаторов, с другой стороны, снять непродуктивную нагрузку на СХД и обеспечила возможность легкого переноса виртуальных машин из тестовой среды в продуктивную.

За год эксплуатации данное решение показало себя с хорошей стороны. Полностью систему выключать пришлось два раза: когда к СХД была докуплена полка расширения EXP3000 и было решено реорганизовать диски RAID-массивов в enclosure loss protection конфигурацию, что осуществляется методом перестановки зеркальных пар в нужном порядке на выключенной системе. Второй раз СХД выключали во время проведения ремонтных работ на самой СХД (также планово). К концу года ресурсы данной схемы стали подходить к концу и потребовалось спланировать и осуществить дальнейшее расширение. Приводящих к останову в рабочее время сбоев в системе виртуализации или в аппаратной инфраструктуре не было совсем.

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

В качестве основы новой аппаратной инфраструктуры было выбрано шасси  IBM Bladecenter H с SAS коммутаторами IBM SAS Connectivity Module, гигабитными Ethernet коммутаторами Nortel L2/3 и СХД IBM DS3524 c полкой расширения EXP3524 и 24-мя 300 GB SAS дисками в RAID10. В качестве лезвий были выбраны 3 сервера IBM HS22v c 48 ГБ оперативной памяти (6*8Гб) на шестиядерных процессорах Intel x5650.  Гипервизор, на этот раз, было решено разместить на USB Flash для экономии средств на партициях хранения.

Получилось как-то так:

Для осуществления миграции была собрана следующая схема:

Мы разобрали MPIO-подключение к DS3400, изъяв из каждого MPIO-набора по одной HBA и подключили к DS3524, таким образом мы добились того, что «старые» сервера стали видеть обе СХД. Для того, чтобы не возникло проблем с доступом к LUN-ам через разные контроллеры мы были вынуждены на время миграции заглушить по одному контроллеру каждой СХД. В полученной схеме «старые» сервера видят обе СХД, а «новые» – только «новую».

После сборки этой схемы и настройки СХД была применена технология Storage vMotion, которая позволила переместить виртуальные машины между СХД «на живую». Миграция шла целый день.

Следующим этапом была применена технология vMotion, при помощи которой виртуальные машины, опять же, без останова, были перемещены из «старого» кластера серверов в новый.

Напоследок, были перемещены виртуальные машины песочницы. Так как по этим машинам нет SLA, то их тащили по сети  в выключенном состоянии 🙂 при помощи «Change host&datastore» (кажется, для такого сценария маркетологи название поленились придумать). Могли, конечно, сделать красиво через iSCSI datastore, тот же StarWind (надеюсь, ребята, вам доплатят за лишнее упоминание), но было лень возиться :), несмотря на то, что многие машины тут же были помещены в продуктив.

Затем схему вернули в первоначальное состояние и включили оба контроллера. Еще через неделю старую инфраструктуру демонтировали.

В итоге мы получили гибкую вычислительную инфраструктуру с хорошим запасом по расширению производительности. Дальнейшие планы по развитию инфраструктуры включают в себя переход на 10G (о причинах, скорее всего, выйдет заметочка), подключение системы резервного копирования к СХД, ну и дальнейшая набивка лезвиями и дисками.