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

“Как в 2024 году можно хранить что-то в облаке, которое не в РФ?” – прокомментировал читатель Хабр новость о том, как российские девелоперы потеряли доступ к своей проектной документации из-за того, что Autodesk неожиданно заблокировал им аккаунты. 

Возможно, ответ в том, что миграция в отечественные облака представляется сложной и рискованной. Действительно ли это так и как обойти подводные камни при переезде, рассказывает наш директор по ИТ-продуктам Роман Горнев.

Что побудило пойти зарубеж

Чтобы понять, почему в импортных облаках ещё остались российские компании, нужно разобраться, почему они вообще там оказались.

Поговорим о причинах облачной эмиграции и их актуальности на 2024 год.

1. Доверие к бренду

Как было

Считалось, что известность площадки = гарантия надёжности. Мол, там размещаются крупные корпорации под жесткий SLA, а значит, и с системами моей компании всё будет в порядке.

Реалии 2024 года

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

Многие часто “стреляют себе в ногу”, надеясь на удачу в таких вещах. Но правда в том, что многим зарубежным компаниям выгоднее отказаться от аудитории из РФ и потерять часть доходов, чем рисковать попасть под санкции США.

2. Зарубежные площадки не попадают под российскую юрисдикцию

Как было

Бытовало мнение, что контролирующие органы в любой момент могут прийти на российскую площадку и изъять оборудование с данными компании. За рубежом такого риска не было – законы РФ там не распространяются, а значит, никто не имеет права потребовать доступ.

Предположим, у тебя есть 1С, к тебе придут контролирующие органы, скажут – покажи бухгалтерию. А где ещё? Где-то. И в это “где-то” со своими требованиями никто прийти не может

Реалии 2024 года

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

3. “Работает – не трогай”

Этот принцип бытует среди инженеров и системных администраторов – зачем идти на риск и что-то менять, если это может привести к негативным последствиям?

Реалии 2024 года

В один прекрасный день VMware без предупреждения заблокировала учётные записи. Я не смог зайти в свой аккаунт, хотя на счету остались деньги. Так что принцип “когда сломается – будем решать” становится риском. И нужно думать о том, насколько он оправданный, потому что аварийное восстановление обычно проходит гораздо болезненнее, чем плановое. Во втором случае мы планируем работы, перерывы и т.д. Если восстановление аварийное, велик риск потери данных, даже при наличии бэкапов.

Проблемы миграции

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

– Сложное проектирование

В большинстве случаев крупные инфраструктуры – хаотические. Они росли и развивались постепенно, без плана и документирования изменений. Грубо говоря: потребовался ресурс – его добавили, понадобилась система – её сделали. 

В такой структуре много взаимосвязанных, но не понятно, как именно, систем. Вероятно, есть и атавизмы, которыми никто не пользуется – и это нормально. Такое часто бывает – до сих пор платишь деньги, там уже никто не работает, но отследить это очень сложно как раз по той причине, что элементов очень много, и как они связаны – неизвестно. Особенно если сменился персонал, который всё это обслуживал – тем, кто пришёл на их место, сложно и долго разбираться в запутанном наследии.

– Потеря ресурсов

Самостоятельно бесшовную миграцию осуществить практически невозможно. Перерыв в работе систем всё равно будет. И чем крупнее структура, тем он будет дольше. А пока системы стоят, компания теряет время, данные, деньги. 

Также ей необходимо уведомить пользователей – почему и как долго сервис не будет доступен.

– Сложные процессы

Ресурсы необходимо разобрать, выгрузить, сохранить и перенести на российскую площадку. И хорошо, если есть коннекторы, которые позволяют это сделать с минимальными трудозатратами. Но даже с ними избежать простоя в несколько дней – это огромная, сложная работа. 

Поэтому зачастую проще оставить как есть, чем пытаться что-то сделать, понимая, что объём работы огромный – обычно у персонала нет на это ни времени, ни компетенций.

– Зависимость приложений от облака – использование Cloud Native

Если коротко – в рамках этого подхода приложения создаются и запускаются на базе сервисов и компонентов, привязанных к поставщику облачных услуг. 

И если обычно обмен данными выглядит как:

ВМ приложения делает запрос к ВМ базы данных по IP

То в случае Cloud Native это будет:

Приложение делает запрос к БД через URL, а БД находится у поставщика услуг

Чтобы после миграции всё продолжило работать в привычном режиме, необходимо перестраивать всю архитектуру.

Мифическая облачная сырость

Популярно мнение, что все российские ИТ-решения “сырые”, на них невозможно поддерживать стабильность и надёжность. На практике это справедливо лишь для отечественных кластеров: российская виртуализация, в большинстве, действительно не предназначена для построения публичных облаков. 

В целом же практически все облака российских поставщиков услуг построены на опенсорсных либо на проприетарных импортных решениях с серьёзной доработкой. Все они “родились” далеко не в 2022 году, а гораздо раньше. Они уже прошли опыт становления от “юношества” до “зрелости”, и  мы уверенно можем сказать – да, оно 100% работает. 

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

Как мигрировать с минимальными потерями

Вариант 1: самостоятельно 

В этом случае вам потребуется выполнить следующий алгоритм

Шаг 1: оценить текущую инфраструктуру

1. Посчитайте все компоненты текущей инфраструктуры: серверы, базы данных, приложения, сервисы, сети и т.д.
2. Определите зависимости между компонентами.
3. Оцените используемые ресурсы (CPU, RAM, дисковое пространство) и пропускную способность сети.
4. Оцените соответствие требованиям регуляторов к безопасности.

Шаг 2: выбрать площадку в РФ

1. Определите необходимые возможности, бюджет, уровень SLA, стоимость потери данных и простоя. Как это делать, рассказывали тут.
2. Протестируйте разные площадки, чтобы оценить их производительность и надёжность.

Шаг 3: спланировать процесс миграции

1. Разработайте детальный план миграции, определите  ответственных лиц и контрольные точки.
2. Выберите сценарий миграции: полный перенос всех компонентов сразу или поэтапно.
3. Идентифицируйте риски (например, простой сервисов, потеря данных, нарушения в работе) и разработайте меры по их минимизации.

Шаг 4: подготовить инфраструктуру

1. Создайте аналогичные окружения в российской облачной инфраструктуре.
2. Настройте VPN или другие способы защищенного подключения между старой и новой инфраструктурой.

Шаг 5: перенести данные и сервисы

1. Создайте резервные копии всех данных и конфигураций.
2. Перенесите данные в новую инфраструктуру, используя инструменты площадок или сторонние решения.
3. Настройте и протестируйте все сервисы в новой инфраструктуре.

Шаг 6: переключиться на новую инфраструктуру

1. Спланируйте переключение на период минимальной нагрузки.
2. Настройте мониторинг всех компонентов новой инфраструктуры для оперативного выявления проблем.
3. Обеспечьте наличие команды поддержки для быстрого реагирования на инциденты.

Шаг 7: пост-миграционные задачи

1. Оптимизируйте конфигурации и процессы для работы в новой инфраструктуре.
2. Обучите сотрудников работе с новой инфраструктурой.
3. Обновите всю документацию, связанную с новой инфраструктурой.

Сроки миграции

• Малые и средние проекты: от нескольких недель до нескольких месяцев.
• Крупные системы: от нескольких месяцев до года и более.

Риски

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

Сложности

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

Вариант 2: делегировать миграцию интегратору

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

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

Я считаю нормальным решением обратиться к компетентным людям, способным предложить план миграции в соответствии с требованиями бизнеса и полностью взять эту задачу. Так поступили, например, ТИОН и Новосибирскэнергосбыт. Они делегировали эту задачу Cortel.

Если вам нужна консультация по миграции из зарубежного облака в российское, заполните форму — мы свяжемся с вами.