Перенесення 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 з технічних або регуляторних причин
На практиці в першій хвилі міграції — 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%.
