Перенос on-premise инфраструктуры в облачные платформы
Мы знаем, что большинство миграций идут не по плану. Не потому что план плохой — а потому что on-premise инфраструктура содержит десятки «скрытых зависимостей», которые никто не документировал последние пять лет. Сервис A неожиданно обращается к сервису B через хардкоженный IP 192.168.1.45. База данных живёт на NFS-шаре, примонтированной на файл-сервере, который обслуживает ещё шесть приложений. Сертификаты для внутреннего PKI выданы на имя хоста, который в облаке изменится. По данным Wikipedia, 80% таких сюрпризов обнаруживаются только на этапе cutover. Поэтому первый месяц любой миграции — это обнаружение, а не перенос.
Как проводится инвентаризация и анализ зависимостей?
Прежде чем двигать первый сервис, нужна полная картина. Инструменты зависят от стека: для VMware-окружений — VMware vRealize Network Insight или CloudPhysics, для bare metal — netstat-based discovery, агенты типа AWS Application Discovery Service.
Собираем следующее:
- Карта сетевых связей между сервисами (какой процесс на каком порту куда ходит)
- Профили потребления ресурсов за 2-4 недели (CPU, RAM, disk IO, network)
- Список внешних зависимостей: AD/LDAP, NFS, SAN, лицензионные серверы
- Приложения с привязкой к железу (USB-ключи, специфичные сетевые карты, GPU)
AWS Migration Hub консолидирует данные от разных discovery агентов и строит граф зависимостей. Это не замена ручному анализу, но хорошая точка старта.
По результатам инвентаризации каждый сервис попадает в одну из категорий:
- Rehost (lift & shift) — виртуалка переезжает как есть, с минимальными изменениями
- Replatform — базу переводим на managed RDS, приложение — без кода-изменений
- Refactor — переписываем для нативного облака (контейнеры, lambda, managed services)
- Retire — сервис не нужен, выключаем
- Retain — остаётся on-premise по техническим или regulatory причинам
На практике в первой волне миграции — 70-80% Rehost, остальное — Replatform. Refactor — это отдельная программа на полгода-год после базового переезда.
Как выглядит реальная миграция: кейс e-commerce
Берём e-commerce компанию: 40 серверов on-premise, три окружения (dev/staging/prod), PostgreSQL кластер на двух нодах с Patroni, Redis, Nginx балансировщики, несколько Python/Node.js сервисов.
Шаг 1: Сетевая основа в AWS. VPC с правильными CIDR, подсети в двух AZ, Transit Gateway, Site-to-Site VPN до on-premise. Пока идёт миграция, обе площадки работают параллельно и видят друг друга.
Шаг 2: Миграция баз данных. Это самое критичное. PostgreSQL мигрируем через AWS DMS с ongoing replication: источник — on-premise Patroni primary, цель — RDS PostgreSQL. DMS настраивается через Terraform:
resource "aws_dms_replication_instance" "migration" {
allocated_storage = 100
apply_immediately = true
auto_minor_version_upgrade = true
engine_version = "3.5.2"
multi_az = false
publicly_accessible = false
replication_instance_class = "dms.r5.large"
replication_subnet_group_id = aws_dms_replication_subnet_group.migration.id
vpc_security_group_ids = [aws_security_group.dms.id]
}
resource "aws_dms_replication_task" "postgres_migration" {
migration_type = "full-load-and-cdc"
replication_instance_arn = aws_dms_replication_instance.migration.replication_instance_arn
replication_task_id = "postgres-main-migration"
source_endpoint_arn = aws_dms_endpoint.source.endpoint_arn
target_endpoint_arn = aws_dms_endpoint.target.endpoint_arn
table_mappings = jsonencode({
rules = [
{
rule-type = "selection"
rule-id = "1"
rule-name = "all-tables"
object-locator = {
schema-name = "%"
table-name = "%"
}
rule-action = "include"
}
]
})
}DMS запускает full load, затем переходит в CDC-режим и реплицирует изменения в реальном времени. Отставание репликации мониторим через CloudWatch метрику CDCLatencySource.
Шаг 3: Приложения в ECS или EKS. Сначала переносим dev, потом staging. Production переезжает последним. Образы собираем в ECR. Application Load Balancer принимает трафик.
Шаг 4: Cutover. Переключение DNS — за несколько минут. TTL снижаем до 60 секунд за сутки до cutover. В момент переключения DMS останавливает репликацию, приложения переконфигурируются на RDS endpoint, трафик идёт только в AWS. On-premise остаётся в режиме read-only ещё неделю как fallback.
Почему важно управлять секретами при миграции?
On-premise секреты (пароли к БД, API ключи) обычно живут в переменных окружения, .env файлах или в корпоративном key vault. В AWS переносим в AWS Secrets Manager. External Secrets Operator в Kubernetes синхронизирует секреты из Secrets Manager в Kubernetes Secrets — приложение ничего не меняет, просто читает из environment variables как раньше.
Какие ошибки допускают 90% команд?
- Лицензии. Windows Server, Oracle, SQL Server — у них Bring Your Own License (BYOL) схемы. Если не учесть при sizing — придёт счёт от Oracle. Средний штраф за нарушение лицензий составляет $50 000–$200 000.
- Backup политики. On-premise бэкапы в облако не переедут автоматически. Нужно настроить AWS Backup или Velero с первого дня.
- Мониторинг в переходный период. Во время миграции трафик идёт через оба места. Prometheus с remote_write в обоих окружениях, единый Grafana — видно все сервисы.
- Security Groups vs Firewall Rules. On-premise firewall policy с 200 правилами — не переносится один в один. Переписываем в Security Groups по принципу least privilege, используя Tags для grouping.
Rehost, Replatform, Refactor: что выбрать?
| Стратегия | Изменения | Срок | Сложность |
|---|---|---|---|
| Rehost | Нет | Дни–недели | Низкая |
| Replatform | Только инфраструктура | Недели–месяцы | Средняя |
| Refactor | Код + инфраструктура | Месяцы–годы | Высокая |
Managed сервисы AWS (RDS, EKS) сокращают operational overhead в 3–5 раз по сравнению с on-premise, согласно нашим замерам.
Ориентиры по срокам
| Масштаб | Что входит | Сроки |
|---|---|---|
| Малый (10-20 серверов) | Rehost + managed DB | 6-10 недель |
| Средний (20-60 серверов) | Rehost + частичный Replatform | 3-5 месяцев |
| Крупный (60+ серверов) | Поэтапная миграция, несколько волн | 6-18 месяцев |
Что входит в работу
- Discovery-отчёт с картой зависимостей и рисками
- План миграции с пошаговыми инструкциями
- Terraform-конфигурации для всей облачной инфраструктуры
- Настройка мониторинга и оповещений (Prometheus/Grafana)
- Документация по эксплуатации и backup-политики
- Обучение команды и пост-миграционная поддержка 2 недели
Наша команда имеет 10+ лет опыта в DevOps и выполнила более 50 успешных миграций. Свяжитесь с нами для анализа вашей инфраструктуры. Закажите аудит уже сегодня и сократите TCO на 30–50%.
