Google Cloud → Azure: Compute Engine, Cloud SQL и GKE

Миграция Google Cloud в Azure требует отдельных решений для Compute Engine, Cloud SQL, Cloud Storage и приложений GKE. Виртуальные машины рассматривают через поддерживаемый процесс Azure Migrate для физических серверов, базы переносят с учётом движка, а объекты — отдельным инструментом. До переключения проверяют доступы, сетевые зависимости, согласованность данных и возврат после новых записей.

Основная проверка технических источников выполнена 6 сентября 2026 года; дополнительные ограничения и сценарии возврата уточнены 8 сентября 2026 года. Перед реализацией сверяйте требования выбранных инструментов с актуальной документацией.

С чего начать миграцию GCP, если приложение использует несколько управляемых сервисов?

Рабочий комплект для миграции.

Скачать шаблон миграции в Excel

Ресурсы, зависимости, переключение и откат — три заполняемых листа, версия от 8 сентября 2026 года. Доступен без заявки.

Запишите владельцев, RPO/RTO, источники записи и условия возврата. После появления новых данных в Azure одного изменения DNS недостаточно: в плане предусмотрены обратная передача, сверка внешних действий или согласованный альтернативный способ восстановления.

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

Для каждого приложения опишите два контура. Первый — обслуживание пользователей: запросы, авторизация, запись данных и ответы. Второй — эксплуатация: выпуск новой версии, доставка секретов, мониторинг, резервные копии и восстановление. Если перенесён только первый контур, приложение может работать до ближайшего обновления сертификата или сбоя. Команда должна подтвердить оба до завершения миграции.

Составьте реестр ресурсов по GCP projects и владельцам. Важны общие сети, централизованные учётные записи, shared-сервисы, связь с корпоративной системой идентификации и ограничения организации. Не предполагается, что границы Google Cloud project автоматически соответствуют Azure subscription или resource group. Целевую структуру выбирают по полномочиям, ответственности, политике и управлению расходами.

Затем определите, что именно должно измениться. Возможно, задача состоит в переносе корпоративного приложения ближе к Microsoft-среде, а аналитический контур пока сохраняется в GCP. Это допустимый вариант, если зависимость измерена и согласована. Но если цель — полностью прекратить использование Google Cloud, оставшийся вызов API, хранилище секретов или расписание задания означает незавершённый переезд.

Исходный компонент	Рабочая единица переноса	Главная проверка
Compute Engine	Гостевая ОС, приложение, диски	Поддержка конфигурации и запуск без зависимости от среды GCP
Cloud SQL	Конкретный движок и база	Версии, расширения, права, способ передачи изменений
Cloud Storage	Объекты и их используемые свойства	Имена, метаданные, ссылки, доступы и финальное состояние
GKE	Приложение, образы, декларации и постоянные данные	Облачные интеграции Kubernetes и эксплуатация на назначении
Pub/Sub, функции, аналитические службы	Поведение и контракты приложения	Поддержка нужной семантики и объём переработки

Таблица служит для обследования. Она не утверждает взаимозаменяемость сервисов и не выбирает целевой продукт за владельца приложения. Общий контекст размещения можно разобрать через облачные технологии для бизнеса, а оценку собственно переезда — через Azure migration, data residency и FinOps.

Текстовое пояснение схемы

1. Карта GCP. Compute Engine; Cloud SQL, Storage; GKE, Pub/Sub, IAM.
2. Цель в Azure. Маршрут для VM; Совместимость БД; Изменения в GKE.
3. Репетиция. Копирование; Метаданные файлов; Интеграции и права.
4. Переключение. Остановка записи; Финальная сверка; Приёмка в Azure.

Первая новая запись — граница для простого возврата. После неё нужны обратная передача данных и сверка либо исправление на целевой площадке в Azure.

Какой маршрут Azure Migrate применяют к Compute Engine?

Microsoft включает виртуальные машины из Google Cloud в процесс миграции машин как физических серверов. Термин описывает способ переноса: Azure Migrate работает с гостевой системой через агентный процесс. Это не означает, что исходная Compute Engine VM становится физическим сервером или что Azure получает управление гипервизором Google.

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

Разделяйте обнаружение и оценку ресурсов от выполнения репликации. Документация Microsoft для агентного переноса из публичных облаков указывает отдельный replication appliance; ранее установленный компонент обнаружения не заменяет его. В проекте должны быть выделены ресурсы, согласованы привилегии и подтверждена сетевая доступность. Требования следует сверять в текущей инструкции непосредственно перед развёртыванием.

Для всех новых агентных миграций в этом процессе Microsoft требует simplified appliance — актуальный компонент репликации. Та же инструкция указывает 30 сентября 2026 года как дату прекращения поддержки classic appliance. Перед проектом проверяйте текущий статус и вариант компонента, а не только наличие работающего appliance: старый учебный стенд не следует автоматически превращать в основу нового переноса.

На этом этапе особенно полезно проверить зависимости от исходной среды. Найдите startup scripts, обращения к метаданным инстанса, автоматическое получение учётных данных, привязки к имени машины и сетевым адресам. Эти механизмы не следует механически переносить в Azure. Для каждого укажите, нужен ли он приложению после переезда и каким согласованным механизмом будет заменён.

Отдельно проверьте корпоративный доступ. Если приложение использует доменную аутентификацию, переезд VM не равен миграции домена. Microsoft Entra ID и Active Directory решают разные задачи; базовое различие описано в материале Active Directory и Entra ID. Определите, где остаётся источник учётных записей и какие сетевые зависимости нужны для входа пользователей и работы служб.

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

Экспорт образа Compute Engine — самостоятельный возможный проектный вариант, а не обязательный этап этого процесса Azure Migrate. Для него отдельно проверяют официальные ограничения экспорта, формат, лицензии и подготовку гостевой ОС. Без такой проверки нельзя обещать, что любой образ GCP удастся превратить в загружаемый Azure-диск. Если выбран агентный маршрут, не смешивайте с ним требования и ограничения другого инструмента.

Как переносить Cloud SQL и когда возможна онлайн-миграция PostgreSQL?

Cloud SQL — управляемая база, поэтому её перенос не выполняется копированием диска приложения Compute Engine. Начните с движка: PostgreSQL, MySQL и SQL Server требуют отдельных проверок. Внутри одного движка значение имеют версия, расширения, права, особенности схемы, фоновые задачи и используемые способы подключения. Сначала выбирают совместимое назначение, затем способ переноса и переключения.

Для PostgreSQL существует конкретный документированный маршрут. В обзоре службы миграции Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL указан среди поддерживаемых источников для онлайн- и офлайн-переноса. Онлайн-режим включает первоначальную копию, репликацию изменений и финальное переключение. Обзор требует первичные ключи во всех таблицах для онлайн-миграции.

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

Для других движков Cloud SQL не переносите вывод о поддержке PostgreSQL по аналогии. Потребуйте официальную поддержку своей пары источник–назначение и испытайте выбранную процедуру. Если команда предлагает логический экспорт и импорт, измерьте полное время вместе с восстановлением объектов, проверками и переключением. Время создания файла выгрузки — только одна часть окна.

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

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

Для базы на целевой стороне сразу настройте и испытайте резервное копирование. Проверьте восстановление в отдельную среду и способность приложения подключиться к восстановленной копии. Это особенно важно, если на GCP восстановление раньше выполняла другая команда. Раздел ответственности должен быть понятен до снятия исходного сервиса с эксплуатации; полезная основа — руководство по Azure Backup и DR.

Если для PostgreSQL выбран путь pg_dump и импорта, зафиксируйте параметры выгрузки и отдельно сопоставьте владельцев объектов, роли и права на целевой стороне. Не предполагайте, что логическая копия автоматически сохраняет всю модель доступа. До включения репликации также выясните, требуют ли необходимые изменения исходных настроек перезапуска Cloud SQL, и включите подтверждённые остановки в согласованное окно.

Как перенести Cloud Storage через AzCopy и проверить имена, метаданные и доступ?

Microsoft документирует копирование объектов Google Cloud Storage в Azure Blob Storage через AzCopy. В этом маршруте на стороне Google используется ключ service account, на стороне Azure — Microsoft Entra ID либо SAS. Путь к файлу ключа задаётся через GOOGLE_APPLICATION_CREDENTIALS. Передача данных идёт непосредственно между сервисами хранения через Put Block From URL.

Проверьте, разрешает ли политика организации создание и использование service account key. Не отключайте защитное правило только потому, что пример инструмента ожидает ключ. При несовместимости выбранного маршрута с политикой требуется согласованное решение или другой поддерживаемый способ передачи. Учётные данные размещают в защищённой среде, ограничивают область доступа и отзывают после завершения работ.

Основная особенность этого переноса — различия в именах. Документация AzCopy описывает замену точек в именах buckets на дефисы, подчёркиваний на дефисы и преобразование повторяющихся дефисов. Кроме того, завершающие точки в именах объектов или сегментах пути обрезаются при копировании. Следовательно, существующие ссылки и правила приложения необходимо сверять с фактическими именами назначения.

Создайте таблицу соответствия для переименованных контейнеров и объектов. Она нужна разработчикам, интеграторам и тем, кто проверяет документы. Если приложение строит путь из идентификатора клиента, протестируйте этот алгоритм на новых правилах. Если полные адреса объектов хранятся в базе, оцените объём их преобразования до массового переноса. Не полагайтесь на то, что изменение одного параметра STORAGE_URL исправит исторические записи.

Метаданные требуют отдельного решения. По умолчанию режим ExcludeIfInvalid исключает несовместимые метаданные и записывает предупреждение. FailIfInvalid не копирует соответствующий объект; RenameIfInvalid пытается сохранить смысл через преобразование ключей. Выбор зависит от приложения. Если ключ определяет срок хранения или запускает обработку, молчаливое принятие предупреждений недопустимо: владелец данных должен выбрать и проверить поведение.

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

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

Что нужно переработать при переносе GKE и зависимостей от Pub/Sub?

Для GKE разумно планировать перенос приложения в новый целевой контейнерный контур. Это архитектурная рекомендация: один общий формат Kubernetes не доказывает автоматическую переносимость всех возможностей управляемого кластера. Не копируйте его worker-узлы как обычные VM в надежде получить работоспособный AKS. Сначала опишите требования нагрузки, затем выбирайте целевую платформу и метод доставки данных.

Инвентаризируйте образы, namespaces, deployments, сервисы, ingress, конфигурацию, секреты, постоянные тома и контроллеры. Отдельно отметьте элементы, зависящие от GCP: способ доступа workloads к облачным ресурсам, балансировщики, storage classes, DNS, наблюдаемость и правила масштабирования. Для каждого такого элемента нужно решение и проверка в целевой архитектуре, а не простая замена названия провайдера в YAML.

Состояние приложения заслуживает отдельного маршрута. Если база находится в Cloud SQL, её план не должен растворяться в задаче Kubernetes. Если данные хранятся на persistent volumes, определите, кто обеспечивает их согласованную копию и восстановление. Проверьте сессии, временные файлы, блокировки и последовательность запуска: приложение, считающееся stateless, иногда фактически хранит важное состояние внутри pod.

Для очередей и событий составьте контракт поведения. Важны подтверждение обработки, повторная доставка, порядок, дедупликация, задержанные сообщения, необработанные ошибки и максимальное время хранения. Предполагаемый сервис Azure оценивают по этому контракту. Таблица похожих продуктов недостаточна, если разработчик рассчитывает на конкретное поведение Pub/Sub, а после переноса меняется способ повторной обработки.

Перед переключением определите судьбу накопленных сообщений. Один вариант — дождаться обработки очереди источника и остановить производителей; другой требует явно спроектированного переноса или согласованной параллельной работы. Выбранный вариант проверяют на повторной доставке и сбое потребителя. Универсальный совет «запустить обе стороны одновременно» может привести к двойным внешним операциям.

Для доставки изменений используйте воспроизводимую сборку, зафиксированные версии образов и понятный процесс возврата приложения. Основы командного выпуска описаны в руководстве по Azure DevOps. План по идентификации нагрузки согласуйте с общей моделью Microsoft Entra ID, сохраняя различие между человеческой учётной записью и полномочиями приложения.

Для каждого постоянного тома GKE запишите CSI-драйвер, storage class, зону, режим доступа и способ получения согласованной копии. На целевом классе AKS испытайте восстановление и работу приложения с томом. Отдельно сопоставьте GKE Workload Identity с выбранной моделью AKS и Microsoft Entra: перенос Kubernetes-манифестов сам по себе не переносит облачные разрешения.

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

Azure Migrate не предоставляет встроенный откат после финальной миграции и остановки источника. Возврат новых данных требует отдельного заранее испытанного механизма либо согласованного сценария восстановления с явно принятым RPO. Сохранение исходных ресурсов не создаёт обратную репликацию. В плане также можно выбрать устранение сбоя на целевой стороне, если возврат после новых записей несёт больший риск.

До окна назначьте владельцев DNS и сертификатов, проверьте перенос или перевыпуск TLS/mTLS и разрешённые исходящие IP у внешних систем. После переключения контролируйте соединения к прежнему Cloud SQL, клиентские кэши, пулы и партнёрские интеграции: истечение TTL само по себе не подтверждает завершение перехода.

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

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

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

Самая важная граница отката — первая производственная запись в назначение. До неё исходная система может оставаться актуальным источником, если целевые тесты не меняли производственное состояние. После неё простой возврат DNS в Google Cloud оставит новые Azure-транзакции в другой системе. Пользователь увидит исчезнувший документ или повторно выполнит операцию, которую сервис уже принял.

Заранее выберите, как действовать после этой границы. Возможны испытанная обратная передача данных с разрешением конфликтов либо исправление проблемы на Azure. Если предусмотрена потеря части изменений, её предел и право принятия решения должны быть явно согласованы с бизнесом. Нельзя скрывать потерю данных за формулировкой «мы сохраним старый кластер на всякий случай».

Контролируйте, что пишет каждая сторона после смены маршрутизации. DNS не отключает давно установленные соединения, расписания и сторонние системы с сохранёнными адресами. Мониторинг должен показывать обращения к источнику и ошибки назначения. Для внешних действий — платежей, уведомлений, выдачи документов — используйте проверку бизнес-результата и защиту от повторной обработки, соответствующую приложению.

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

Как спланировать регион, расходы и ответственность на примере компании?

Условный пример: компания обрабатывает клиентские документы в GCP. Веб-приложение работает на Compute Engine, реестр документов — в Cloud SQL for PostgreSQL, файлы — в Cloud Storage, а уведомления доставляет отдельный обработчик. Это учебная ситуация для разбора решений, не опубликованный клиентский кейс и не основание для оценки сроков любого похожего проекта.

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

Следующий тест выявляет несовместимый ключ метаданных. Инженер видит успешное копирование объекта и предупреждение, но обработчик не узнаёт тип документа. Команда выбирает согласованное преобразование, дополняет контрольный манифест и повторяет функциональную проверку. Этот результат показывает, зачем пилоту нужны сложные данные и реальные бизнес-действия: без них можно принять неполный перенос за завершённый.

В плане производства отдельно фиксируют момент остановки новых документов, проверку финального состояния базы и хранилища, перевод обработчика и разрешение новых загрузок. Владельцы заранее выбирают стратегию после первых записей на Azure. До этого момента сохранённый GCP-контур остаётся вариантом возврата; после него уже требуется согласование новых данных или исправление на назначении.

Финансовая модель включает исходящий трафик Google Cloud, операции чтения объектов, временное дублирование ресурсов, резервные копии, наблюдаемость и работу команды. Учитывают действующие обязательства по исходному облаку и расходы на сохранение старой среды. Не обещайте экономию по одному сравнению размера VM: управляемые базы, журналы и межоблачные обращения могут изменить результат.

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

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

Что передать эксплуатации и когда считать выход из Google Cloud завершённым?

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

Подтвердите отсутствие обязательных обращений к Google Cloud в согласованной области проекта. Для этого используйте инвентаризацию, журналы, конфигурацию приложения и проверку рабочих сценариев. Одного отсутствия пользовательского трафика на старом балансировщике недостаточно: ночная выгрузка, функция, API-ключ или архив могут оставаться активными. Назовите исключения явно и передайте их владельцам.

Отзыв временных доступов и удаление ресурсов выполняйте по принятому плану. Перед удалением уточняют сроки хранения, наличие нужных копий и проверенное восстановление. Если часть GCP остаётся для архива или аналитики, переезд конкретного приложения может быть завершён, но полным выходом из Google Cloud это называть нельзя. Такая точность помогает финансам и безопасности принимать правильные решения.

Для других исходных платформ доступны отдельные разборы: Oracle Cloud → Azure и Yandex Cloud → Azure. Проверяйте маршрут для конкретного провайдера: ограничения одной платформы не переносятся автоматически на другую.