Миграция в облако: как безболезненно перейти с зарубежного на отечественное
Как в 2024 году можно хранить что-то в облаке, которое не в РФ?”
– прокомментировал читатель Хабр новость о том, как российские девелоперы потеряли доступ к своей проектной документации из-за того, что Autodesk неожиданно заблокировал им аккаунты.
Возможно, ответ в том, что миграция в отечественные облака представляется сложной и рискованной. Действительно ли это так и как обойти подводные камни при переезде?
Что побудило пойти зарубеж
Чтобы понять, почему в импортных облаках ещё остались российские компании, нужно разобраться, почему они вообще там оказались.
Поговорим о причинах облачной эмиграции и их актуальности на 2024 год.
1. Доверие к бренду
Как было
Считалось, что известность площадки = гарантия надёжности. Мол, там размещаются крупные корпорации под жесткий SLA, а значит, и с системами моей компании всё будет в порядке.
Реалии 2024 года
Бренд в сфере облачных технологий уже не играет никакой роли. Когда мы в CORTEL решали вопрос с отказом от продукции Microsoft, один сотрудник был уверен, что, корпорация никогда не заблокирует свои ресурсы в России. И буквально через два месяца это случилось.
Многие часто “стреляют себе в ногу”, надеясь на удачу в таких вещах. Но правда в том, что многим зарубежным компаниям выгоднее отказаться от аудитории из РФ и потерять часть доходов, чем рисковать попасть под санкции США.
2. Зарубежные площадки не попадают под российскую юрисдикцию
Как было
Бытовало мнение, что контролирующие органы в любой момент могут прийти на российскую площадку и изъять оборудование с данными компании. За рубежом такого риска не было – законы РФ там не распространяются, а значит, никто не имеет права потребовать доступ.
Предположим, у тебя есть 1С, к тебе придут контролирующие органы, скажут – покажи бухгалтерию. А где ещё? Где-то. И в это “где-то” со своими требованиями никто прийти не может
Реалии 2024 года
Персональные данные за пределами РФ хранить нельзяхранить нельзя. В случае проверки пострадают не те, кто оставил данные здесь, а те, кто хранит их на зарубежных площадках.
3. “Работает – не трогай”
Этот принцип бытует среди инженеров и системных администраторов – зачем идти на риск и что-то менять, если это может привести к негативным последствиям?
Реалии 2024 года
В один прекрасный день VMware без предупреждения заблокировала учётные записи. Я не смог зайти в свой аккаунт, хотя на счету остались деньги. Так что принцип “когда сломается – будем решать” становится риском. И нужно думать о том, насколько он оправданный, потому что аварийное восстановление обычно проходит гораздо болезненнее, чем плановое. Во втором случае мы планируем работы, перерывы и т.д. Если восстановление аварийное, велик риск потери данных, даже при наличии бэкапов.
Проблемы миграции
Теперь о том, с какими сложностями сталкиваются компании при переходе с зарубежного на российское облако.
– Сложное проектирование
В большинстве случаев крупные инфраструктуры – хаотические. Они росли и развивались постепенно, без плана и документирования изменений. Грубо говоря: потребовался ресурс – его добавили, понадобилась система – её сделали.
В такой структуре много взаимосвязанных, но не понятно, как именно, систем. Вероятно, есть и атавизмы, которыми никто не пользуется – и это нормально. Такое часто бывает – до сих пор платишь деньги, там уже никто не работает, но отследить это очень сложно как раз по той причине, что элементов очень много, и как они связаны – неизвестно. Особенно если сменился персонал, который всё это обслуживал – тем, кто пришёл на их место, сложно и долго разбираться в запутанном наследии.
– Потеря ресурсов
Самостоятельно бесшовную миграцию осуществить практически невозможно. Перерыв в работе систем всё равно будет. И чем крупнее структура, тем он будет дольше. А пока системы стоят, компания теряет время, данные, деньги.компания теряет время, данные, деньги.
Также ей необходимо уведомить пользователей – почему и как долго сервис не будет доступен.
– Сложные процессы
Ресурсы необходимо разобрать, выгрузить, сохранить и перенести на российскую площадку. И хорошо, если есть коннекторы, которые позволяют это сделать с минимальными трудозатратами. Но даже с ними избежать простоя в несколько дней – это огромная, сложная работа.
Поэтому зачастую проще оставить как есть, чем пытаться что-то сделать, понимая, что объём работы огромный – обычно у персонала нет на это ни времени, ни компетенций.
– Зависимость приложений от облака – использование Cloud Native
Если коротко – в рамках этого подхода приложения создаются и запускаются на базе сервисов и компонентов, привязанных к поставщику облачных услуг.
И если обычно обмен данными выглядит как:
ВМ приложения делает запрос к ВМ базы данных по IP
То в случае Cloud NativeCloud Native это будет:
Приложение делает запрос к БД через URL, а БД находится у поставщика услуг
Чтобы после миграции всё продолжило работать в привычном режиме, необходимо перестраивать всю архитектуру.
Мифическая облачная сырость
Популярно мнение, что все российские ИТ-решения “сырые”, на них невозможно поддерживать стабильность и надёжность. На практике это справедливо лишь для отечественных кластеров: российская виртуализация, в большинстве, действительно не предназначена для построения публичных облаков.
В целом же практически все облака российских поставщиков услуг построены на опенсорсных либо на проприетарных импортных решениях с серьёзной доработкой. Все они “родились” далеко не в 2022 году, а гораздо раньше. Они уже прошли опыт становления от “юношества” до “зрелости”, и мы уверенно можем сказать – да, оно 100% работает.
Проприетарные решения сегодня без вендорской техподдержки, но мы умеем поддерживать работоспособность и надёжность самостоятельно по жесткому SLA.
Как мигрировать с минимальными потерями
Вариант 1: самостоятельно
В этом случае вам потребуется выполнить следующий алгоритм
Шаг 1: оценить текущую инфраструктуру
- Посчитайте все компоненты текущей инфраструктуры: серверы, базы данных, приложения, сервисы, сети и т.д.
- Определите зависимости между компонентами.
- Оцените используемые ресурсы (CPU, RAM, дисковое пространство) и пропускную способность сети.
- Оцените соответствие требованиям регуляторов к безопасности.
Шаг 2: выбрать площадку в РФ
- Определите необходимые возможности, бюджет, уровень SLA, стоимость потери данных и простоя. Как это делать, рассказывали тут.Как это делать, рассказывали тут.
- Протестируйте разные площадки, чтобы оценить их производительность и надёжность.
Шаг 3: спланировать процесс миграции
- Разработайте детальный план миграции, определите ответственных лиц и контрольные точки.
- Выберите сценарий миграции: полный перенос всех компонентов сразу или поэтапно.
- Идентифицируйте риски (например, простой сервисов, потеря данных, нарушения в работе) и разработайте меры по их минимизации.
Шаг 4: подготовить инфраструктуру
- Создайте аналогичные окружения в российской облачной инфраструктуре.
- Настройте VPN или другие способы защищенного подключения между старой и новой инфраструктурой.
Шаг 5: перенести данные и сервисы
- Создайте резервные копии всех данных и конфигураций.
- Перенесите данные в новую инфраструктуру, используя инструменты площадок или сторонние решения.
- Настройте и протестируйте все сервисы в новой инфраструктуре.
Шаг 6: переключиться на новую инфраструктуру
- Спланируйте переключение на период минимальной нагрузки.
- Настройте мониторинг всех компонентов новой инфраструктуры для оперативного выявления проблем.
- Обеспечьте наличие команды поддержки для быстрого реагирования на инциденты.
Шаг 7: пост-миграционные задачи
- Оптимизируйте конфигурации и процессы для работы в новой инфраструктуре.
- Обучите сотрудников работе с новой инфраструктурой.
- Обновите всю документацию, связанную с новой инфраструктурой.
Сроки миграции
- Малые и средние проекты: от нескольких недель до нескольких месяцев.
- Крупные системы: от нескольких месяцев до года и более.
Риски
- Возможны простои сервисов при переключении.
- Риск потери данных.
- Временами возможно снижение производительности.
- Риски, связанные с защитой информации и соответствием требованиям регуляторов.
Сложности
- Требуется тщательное планирование и проектирование.
- Трудность интеграции с существующими системами.
- Необходимо учитывать требования законодательства и регуляторов.
Вариант 2: делегировать миграцию интегратору
Профессиональные поставщики услуг обладают необходимыми знаниями, инструментами и опытом. Это позволяет минимизировать риски и сократить время на миграцию,обеспечив при этом высокий уровень безопасности и надежности данных и сервисов.
Когда приходит интегратор и разворачивает систему, у заказчика всегда есть прописанная архитектура и схема работы с ней: все понимают, где и какие элементы, как они между собой связаны и взаимодействуют.
Я считаю нормальным решением обратиться к компетентным людям, способным предложить план миграции в соответствии с требованиями бизнеса и полностью взять эту задачу. Так поступили, например, ТИОН ТИОНи Новосибирскэнергосбыт. Они делегировали эту задачу Cortel.
Если вам нужна консультация по миграции из зарубежного облака в российское, заполните форму — заполните форму - мы свяжемся с вами.