Миграция в публичное облако: успеть за 10 минут
Запросить демо
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Оставить заявку
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Узнать стоимость
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Попробовать бесплатно
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Регистрация в консоли
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Быть в теме

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

14.04.2020 11 минут 255

Александр Кузьмин

Старший инженер

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

О спикере и теме вебинара

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

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

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

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

Важные аспекты при миграции

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

Автоматизированная миграция

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

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

download_agent.JPG

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

agent_win.JPG

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

agent4.JPG

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

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

служба.JPG

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

start_replication.JPG

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

lin_agent1.JPG

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

lin_agent2.JPG

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

lin_agent3.JPG

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

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

migration_plan1.JPG

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

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

subnet.JPG

В окне 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, где работают реплицируемые виртуальные машины.

Cloud_site.JPG

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

Вопросы и ответы

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

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

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

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

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

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

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

Запись вебинара

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

Не пропустите самые важные, интересные и полезные статьи недели

Ваш e-mail успешно подписан.

Смотрите также