Миграция в публичное облако: успеть за 10 минут

Меня зовут Александр Кузьмин, я старший инженер КРОК Облачные сервисы.

Вебинар посвящен миграции данных в Облако КРОК.

Как показывает опыт КРОК Облачные сервисы, процесс миграции не труднее развертывания виртуальной машины в облаке.

На вебинаре я расскажу, как мигрировать инфраструктуры в публичное облако без особых усилий, а также покажу, как мигрировать виртуальную машину с виртуального гипервизора в облака КРОК с помощью программного обеспечения Hystax.

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

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

Предварительное планирование

Существует два вида миграции. Миграция at once — это миграция из точки А в точку Б, после чего инфраструктура в точке А отключается.

Посистемная миграция — это поэтапная и последовательная миграция, например, подсистем (TST, DEV, PRD) в целевую среду. В таком случае важно учитывать связность этих сред и их компонентов.

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

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

Планирование сетевой инфраструктуры

На простоту миграции влияют связи между площадками.

Например, если вся система мигрирует из точки А в точку Б (1-to-1), можно просто переключиться на новую среду.

При посистемной миграции и поэтапного переноса подсистем TST, DEV и т. д., необходимо учитывать, как будут взаимосвязаны подсистемы на разных площадках.

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

Выбор механизма миграции данных

На выбор механизма миграции для каждой информационной системы влияют несколько параметров:

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

Кроме того, оптимальный метод миграции зависит от ситуации и особенностей бизнеса:

• Если исходная структура работает «на честном слове» или установлена на устаревшей операционной системе, самый рациональный вариант миграции — создание с нуля новой инфраструктуры на основе более современной операционной системы.
• Для миграции данных между системами в разных странах, передачи большого объема данных или в случае использования узкого канала связи между исходной и целевой инфраструктурой можно использовать отчуждаемые носители/резервные копии.
• Синхронизация СХД и файловые системы позволяют синхронизировать точку А и точку Б и передать данные на блочном уровне.
• Некоторые приложения, например, базы данных или Exchange, позволяют проводить синхронизацию средствами приложения, т. е. создании реплики в целевой инфраструктуре.
• Для миграции данных между облаками или гипервизорами, в том числе в случае смены площадки или провайдера, можно провести репликацию на уровне гипервизора или операционной системы.
• Для миграции можно также воспользоваться автоматизированными средствами, например, приложением Hystax.

Меры предосторожности

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

• Необходимо провести предварительную проверку и как минимум включить и выключить оборудование, чтобы убедиться, что информационная система в целевой инфраструктуре благополучно переживет банальную перезагрузку системы.
• Желательно всегда проводить полное резервное копирование каждой мигрирующей системы, а также срезы резервных копий.
• Если информационная система переносится поэтапно отдельными средами, не рекомендуется вносить какие-либо изменения, пока все подсистемы не перенесены.
• Необходимо создавать промежуточные точки возврата, которые позволяют вернуть систему в исходное состояние, если в целевой среде что-то работает некорректно или происходит что-то непредвиденное.
• В случае изменения архитектуры информационной системы при миграции, необходимо проводить тестирование работы системы и учитывать обратную связь от конечных пользователей о том, насколько корректно работает информационная система на новой площадке.
• Время миграции рекомендуется планировать с запасом, потому что на любом этапе миграции любой информационной системы могут возникать непредвиденные сложности.

Типичные проблемы при миграции

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

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

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

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

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

Организационное планирование

Тщательное планирование и выполнение всех этапов — залог успешной миграции.

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

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

Для демонстрации миграции установлены две виртуальные машины: Windows и Linux, которые будут перенесены в Облако КРОК с помощью Hystaх.

Первый шаг — выбор компании. На странице Hystax выбираем Download agent > (Компания) > Next.

Второй шаг — выбор агента. Агент позволяет мигрировать все виртуальные машины на уровне гипервизора. Можно также выбрать агента Windows или Linux. Для нашей демонстрации выбираем агент Windows и нажимаем Next.

Оставляем значение default для Machines group.

Нажимаем Download Agent, чтобы скачать агент.

После этого переходим на виртуальную машину для установки агента hystex. Для этого мы запускаем мастер установки, нажимаем Next > Install. Проверить установку можно в папке Службы: Start > Control Panel > Administrative Tools > Services > Hystax Replication Agent.

В списке виртуальных машин мы видим новую машину — Windows Agent, которую только что установили. Следующий шаг — репликация этой виртуальной машины.

Аналогичным образом устанавливается Linux Agent. Для этого агента предлагается выбор операционной системы: CentOS/RHEL или Debian/Ubuntu. Мы будем устанавливать виртуальную машину на Red Hat, поэтому выбираем .rpm package.

Скачать агент можно, нажав Download Agent или скопировав ссылку.

Чтобы запустить агент, нужно нажать ссылку:

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

После завершения репликации необходимо создать план миграции, выбрав Migration plans > Add. В появившемся окне Add Migration Plan указывается имя плана миграции (в нашем случае — Demo_plan) и выбираются виртуальные машины, которые нужно добавить в план миграции.

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

Нам осталось только добавить в план миграции Subnet ID, который мы копируем в параметрах Облака КРОК: Консоль управления > Подсети.

В окне Add Migration Plan также можно вносить изменения в экспертном режиме на вкладке Expert, где представлена информация о виртуальных машинах.

После создания плана миграции мы можем запустить и развернуть наши виртуальные машины в Облаке КРОК. Для этого выбираем план миграции в разделе Migration plans и нажимаем Run migration. В появившемся окне нажимаем Next, указываем имя сайта в поле Cloud Site Name.

Кроме того, можно выбрать время Snapshot time, которое будет определять на основе какой именно реплики разворачиваются виртуальные машины. После этого остается только начать миграцию, нажав кнопку Run migration.

В hystax в окне Cloud Sites указан созданный Demo_cloud_site со статусом Creating, на который мы мигрируем виртуальные машины, и Cloud_Site со статусом Running, где работают реплицируемые виртуальные машины.

Эти же машины можно увидеть в окне Облако КРОК в статусе Running, а при обращении по адресу виртуальной машины в браузере открывается начальная страница на уже запущенной виртуальной машине.

Что делать, если в ходе миграции происходит сбой?

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

Все зависит от серьезности сбоя. Например, при посистемной миграции сбой может произойти после переноса подсистемы TST при миграции DEF, пока подсистема PRD продолжает работать в исходной среде. В этом случае необходимо развернуть ПО в исходной среде и проверить причины сбоя, после чего повторно запустить миграцию той среды, при переносе которой произошел сбой.

Какие проблемы ждут при лицензировании ПО при миграции виртуальных машин в связи со сменой оборудования?

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

Поставщики, как правило, предлагают демо-версии ПО, действительные, например, в течение месяца. Такого ПО может быть достаточно для проведения тестирования до решения о том, как будет проводиться миграция.

Спасибо за внимание!

Запись прошедшего вебинара доступна на странице мероприятия.