Реальный мир — опыт миграции SAN

Опубликовано: 21 Апреля, 2023

Введение

Любая часть технологического оборудования имеет конечный срок службы. В какой-то момент оборудование необходимо заменить, желательно в рамках запланированной стратегии замены на протяжении всего жизненного цикла. Недавно цикл замены Вестминстерского колледжа потребовал замены системы хранения — SAN на основе iSCSI, которая находилась в эксплуатации и срок службы которой приближался к концу. Лично я нахожу истории из реальной жизни очень ценными, поэтому я решил поделиться с вами тем, как мы перешли от нашей старой SAN к нашей новой SAN, которая представляет собой устройство Fibre Channel.

Основа

Прежде всего, я заложу основу. Наша SAN на основе iSCSI поддерживала ряд рабочих нагрузок, в том числе:

Кластер VMware из 50 виртуальных серверов, работающий на четырех хостах vSphere 4.0/4.1.
Наши почтовые хранилища Exchange 2007. Наша система Exchange 2007 была полностью физической, пока работала в iSCSI SAN.
Базы данных нашего основного сервера баз данных. Наш основной SQL-сервер — это физический сервер, все базы данных которого хранятся в iSCSI SAN.

Я продолжу, сказав, что я не принимал решение о SAN с требованием, чтобы это было решение Fibre Channel, но выбранный нами окончательный вариант подтолкнул нас к этому пути. Хотя у меня был относительно небольшой опыт работы с Fibre Channel, настроить и запустить его было довольно просто. Честно говоря, моим первоначальным желанием было остаться на iSCSI, но я не был настолько зациклен на этом желании, чтобы отказываться рассматривать решения, отличные от iSCSI.

Вот инфраструктура, которая была у нас до марта 2011 года:

iSCSI SAN — два модуля управления с резервными путями. Система хранения полностью избыточна, как и должно быть.
Одно блейд-шасси Dell M1000e с шестью блейд-модулями Ethernet M3220 сзади. Каждый из этих блейд-модулей Ethernet подключается к порту сетевой карты на каждом сервере.
Четыре хоста VMware ESX, каждый с 6 портами Ethernet, распределенными по трем сетевым картам (две встроенные сетевые карты и мезонинные карты с 2x2 портами). Каждый порт сопоставляется с модулем коммутатора Ethernet в задней части корпуса. В начале процесса у трех хостов ESX было по 32 ГБ ОЗУ каждый, а у одного — 48 ГБ ОЗУ.

Однако мы столкнулись с некоторыми проблемами. Прежде всего, чтобы перейти на Fibre Channel, нам нужно было заменить одну из карт Ethernet в каждом из существующих серверов на карту Fibre Channel, а также заменить два из шести коммутаторов Ethernet в блейд-шасси на Fibre Channel. блейд-модулей, соответствующих новой мезонинной плате Fibre Channel, устанавливаемой на каждом сервере.

Однако, несмотря на то, что шасси M1000e допускает горячую замену блейд-модулей шасси, вы не можете заменить блейд-сервер одного типа, если в одном или нескольких серверах все еще установлены мезонинные карты другого типа. Таким образом, пока у нас были блейд-серверы с Ethernet-картой в слоте, который мы нацеливали на Fibre Channel, мы не могли установить модуль Fibre Channel в шасси. Если бы мы попытались, в шасси был бы механизм, отключающий коммуникационный слот, чтобы предотвратить повреждение. Итак, первым делом нужно было запустить серверы и удалить третий Ethernet-адаптер… сразу после того, как мы добавили один новый хост ESX.

Новое дополнение

В рамках этого процесса миграции мы также приняли решение заменить один из наших существующих серверов ESX с 32 ГБ ОЗУ новым устройством с 96 ГБ ОЗУ; наш кластер становился привязанным к оперативной памяти. Хотите верьте, хотите нет, но купить полностью новый сервер было дешевле, чем просто обновить оперативную память на старом сервере и добавить расширенную гарантию. Чтобы добавить немного глазури на торт, новый сервер имеет два шестиядерных процессора, в то время как в старом устройстве использовались четырехъядерные процессоры. Таким образом, мы получили на 64 ГБ больше оперативной памяти и еще 4 вычислительных ядра за меньшую стоимость, чем стоимость обновления оперативной памяти и продления гарантии.

Мы начали наш процесс с установки vSphere 4.1u1 на новый сервер, применения профиля хоста и добавления этого нового сервера в наш кластер vSphere с 60-дневной льготной лицензией, предоставленной VMware.

Процесс начинается

Очевидно, нам нужно было достичь наших целей миграции с минимальным временем простоя. Итак, мы сделали это грубой силой. Начиная с первого сервера vSphere, мы перевели этот хост в режим обслуживания, что позволило vCenter эвакуировать сервер для нас и автоматически vMotion все его рабочие нагрузки на другие хосты в кластере, включая наш новый блестящий 12-ядерный блок объемом 96 ГБ. После того, как все рабочие нагрузки были эвакуированы, мы вытащили сервер из корпуса, удалили третий адаптер Ethernet и установили адаптер Fibre Channel.

Все было не так.

С этим первым сервером мы столкнулись с проблемой. Нашей первоначальной целью было вытащить карту Ethernet и просто заменить ее новым адаптером Fibre Channel, вставить ее обратно в корпус и снова включить. Когда мы попробовали это с первым сервером, система не загружалась. В ходе дальнейшего исследования мы определили следующее: если какой-либо из серверов в блейд-шасси все еще имел карты Ethernet в слоте, который мы предназначали для адаптеров Fibre Channel, сервер не загружался. Период. По словам Dell, это сделано для предотвращения повреждения системы. Итак, мы немного пересмотрели наш план. Мы вытащили только что установленную карту Fibre, снова запустили сервер без нее, а затем вышли из режима обслуживания, таким образом вернув этот сервер в рабочую среду и способный выполнять рабочие нагрузки. Оттуда мы перешли к другим хостам vSphere и один за другим перевели их в режим обслуживания и удалили третий адаптер Ethernet, а затем вернули их в рабочую среду.

Когда удаление адаптера Ethernet было завершено и ни на одном из серверов в корпусе не было адаптера Ethernet в третьем слоте, мы установили модули коммутатора Fibre Channel в заднюю часть корпуса сервера. Виола! Успех! Модули включились без проблем.

В этот момент мы начали процесс обратного обхода каждого из серверов vSphere, чтобы установить в каждый из них адаптер Fibre Channel. Опять же, мы перевели каждую систему в режим обслуживания и выключили ее. Мы сняли блейд-сервер с шасси сервера и установили адаптер Fibre Channel. После установки мы перезагрузили систему и вернули ее в рабочую среду, за одним исключением: мы полностью вывели из эксплуатации один из 32-гигабайтных 8-ядерных хостов vSphere и применили его лицензию к новому 12-ядерному хосту 96 ГБ. Это было частью нашей стратегии замены.

Возможность подключения к хранилищу

Когда на всех серверах были установлены адаптеры Fibre Channel, и я был уверен, что коммутатор Fibre Channel в задней части корпуса сервера может видеть все порты Fibre Channel, я подключил новую SAN к одному из внешних портов на новом Fibre Channel. переключатели каналов; Я выполнил одно подключение от каждого коммутатора Fibre Channel к каждому порту Fibre Channel на каждом модуле управления в массиве хранения.

Сразу признаюсь, что мой первый опыт работы с Fibre Channel был именно в этом проекте. К счастью, это был кусок пирога. Я просто создал зону на каждом из коммутаторов Fibre Channel и добавил соответствующие порты коммутатора в каждую из новых зон. Наконец, я настроил хосты vSphere так, чтобы они могли видеть тома в новой SAN; Для этой цели я создал небольшой тестовый том.

Миграция начинается

Теперь все было готово. Все серверы vSphere могли видеть как старые, так и новые устройства хранения. Я создал новые LUN в новом массиве хранения и оттуда создал новые тома VMFS. Затем я запустил операцию Storage vMotion для каждой из 50 или около того виртуальных машин, которые нужно было перенести из iSCSI SAN в модуль Fibre Channel. Опять же, это было сделано (почти) без простоев, как и процесс модификации оборудования ранее.

Этот процесс Storage vMotion занял около двух дней. Я столкнулся с небольшими проблемами при переносе одной виртуальной машины, которые мне удалось устранить, отключив машину и переместив ее во время более длительного периода обслуживания.

Результат

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

Несколько лет назад было бы безумием заниматься подобным проектом в рабочее время. Миграция может привести к значительному простою и негативным последствиям для бизнеса. Однако с помощью более чем 150 операций vMotion мы смогли завершить наш проект очень-очень быстро, а бизнес, ну, ничего не заметил. Это именно то преимущество, которое мы должны видеть в нашей виртуальной среде, и такая возможность была одним из драйверов для внедрения виртуальной инфраструктуры.

Есть больше

В начале этой статьи я упомянул, что у нас есть несколько физических серверов, на которых работают SQL и Exchange, а рабочие нагрузки выполняются в сети хранения данных iSCSI. Кроме того, у нас были некоторые другие физические рабочие нагрузки, которые необходимо было перенести на новое оборудование из-за истечения срока аренды существующих устройств. В частности, было два дополнительных физических сервера, которые поддерживали нашу среду SharePoint 2007: один сервер MOSS 2007 и выделенный сервер SQL 2005. Все хранилища для SharePoint и выделенной среды SQL были локальными, и в старой SAN не хранились данные.

Так что мы сделали:

Сервер Exchange 2007. Наша система Exchange 2007 содержит почтовые ящики для 1300 студентов, преподавателей и сотрудников, и все хранилище почты находилось в iSCSI SAN, хотя сам Exchange Server был физическим устройством. Мы использовали PlateSpinPowerConvert для выполнения операции P2V для переноса этого физического сервера в новый расширенный кластер vSphere. Это заняло большую часть субботнего вечера во время расширенного окна обслуживания, но теперь мы полностью виртуализировали эту рабочую нагрузку. Это также помогло удалить базы данных Exchange 2007 из iSCSI SAN. Теперь они хранятся вместе с виртуальной машиной на новом модуле Fibre Channel.
Система SharePoint 2007. Наш корпоративный веб-сайт в настоящее время работает на SharePoint 2007, как и в течение трех лет. Физический сервер использовал хранилище с прямым подключением. Опять же, мы использовали операцию P2V для виртуализации рабочей нагрузки.
SQL 2005. Этот выделенный SQL Server для SharePoint 2007 также использовал хранилище с прямым подключением. Опять же, операция P2V легко виртуализировала эту критическую рабочую нагрузку.

Что осталось?

На данный момент у нас есть еще один физический сервер, который мы собираемся виртуализировать. Наш первичный сервер базы данных — это блейд-сервер, работающий под управлением SQL Server 2008 R2. Этот сервер хранит все свои данные в iSCSI SAN и, к сожалению, до сих пор хранит. Это единственная оставшаяся рабочая нагрузка на SAN. Хотя у меня очень высокий уровень доверия к P2V, мы находимся в такой точке нашего семестра, когда мы не можем позволить себе длительное время простоя, даже в одночасье. Таким образом, мы ждем еще пару недель, прежде чем завершить этот процесс.

Резюме

В общем, я очень доволен конечным результатом. Хотя предстояло предпринять довольно много шагов, ни один из них не был особенно обременительным или трудным. Мы смогли очень быстро переместить весь наш инвентарь VMware в наше новое хранилище и дополнительно консолидировать/виртуализировать наш физический инвентарь с помощью программного обеспечения P2V. На данный момент мы используем среду, которая более чем на 90% виртуальна, и это видно. Нам стало намного легче выполнять техническое обслуживание и развертывать новые услуги, чем раньше, а наша новая сеть хранения данных обеспечивает производительность и емкость, которые помогут нам расти.

Виртуализация