Как переехать в новый ЦОД и не потерять данные

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

Миграция миграции рознь, особенно если речь идет о крупной инфраструктуре с большим количеством бизнес-критичных систем. Срок переноса данных варьируется условно от одной недели до двух-трех месяцев. В зависимости от сложности процесса (например, требований заказчика к минимальному даунтайму систем — то есть фактически 100% непрерывности работы бизнес-приложений в период смены платформы) стоимость проекта также отличается. В процессе переноса могут возникать шероховатости, но срывы сроков и тем более недостаточно эффективная работа систем после миграции исключены, если следовать нескольким рекомендациям.

Семь раз подготовь — один раз проведи миграцию

Правильная подготовка — 90% успеха. Важно предварительно ознакомиться с тем, какую инфраструктуру клиент желает перенести в облако или ЦОД, составить план миграции с зонами ответственности (так называемая RACI-матрица) и с учетом технических характеристик систем и потребности в вычислительных ресурсах. Также необходимо спланировать сетевую инфраструктуру. От пропускной способности каналов как в самом дата-центре провайдера, так и в среде, из которой перенос данных будет проводиться, зависит время, затрачиваемое на весь процесс. Миграцию может осуществить непосредственно заказчик, если он обладает нужными знаниями и опытом. Но часто для задачи привлекают провайдера. Тот для успешной реализации проекта, как правило, проводит экспресс-аудит, представляющий собой консультации с клиентом.

Всегда думай о защите данных

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

Возможно, потребуется оптимизация приложения. Но это не проблема

В крупных компаниях используемые бизнес-системы, как правило, неоднородны. Среди них есть такие, которые были разработаны чуть ли не десятки лет назад. Исторически подобные приложения всегда базировались только на физической инфраструктуре. Из-за устаревшей архитектуры эти приложения крайне неэффективно работают в облаке. Их стоит оставить локально или перенести as is на подобное же физическое оборудование в коммерческий ЦОД.

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

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

Если возможно, используйте автоматизацию

Чтобы существенно упростить жизнь и себе, и провайдеру, стоит использовать инструменты для автоматизированного переноса инфраструктур. Сегодня они эффективно работают даже при смене гипервизора — специального ПО, благодаря которому происходит развертывание виртуальных машин.

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

К счастью, такое случается нечасто, и связано это в первую очередь не с техническими, а с организационными ограничениями. Пример из нашей практики: провайдер, чьей контракт с клиентом истекал, не хотел отпускать компанию, ограничивая пропускную способность канала и мешая автоматизированному копированию информации в K2 Cloud. Пришлось использовать инструменты партизанской работы и вывозить данные на съемных дисках.

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

__________

статья для  Инвест-Форсайт