Облачная миграция за две недели: как COVID-19 сделал то, что не делал год переговоров

Год назад, когда мы с этим клиентом первый раз поговорили про облако, он сказал: «Интересно, но не сейчас. Надо разобраться с внутренними процессами, потом вернёмся». Мы вернулись в марте, в режиме «всё горит, нужно две недели». Так COVID-19 ускорил то, что откладывалось двенадцать месяцев.

Клиент - средняя производственно-торговая компания, примерно 200 человек, собственный небольшой ЦОД в арендованной стойке. Когда в марте их отправили по домам, выяснилось, что on-premise ИТ не рассчитана на 200 человек на удалёнке одновременно. VPN-шлюз согнулся, файловый сервер стал недоступен половине сотрудников, внутренняя CRM через браузер открывалась по три минуты. Разговор про облако стал конкретным за один звонок.

Почему Yandex Cloud

Выбор был не очень долгим. Клиент работает в России, данные не хочет класть в иностранные дата-центры (формально не КИИ, но осторожность разумная). Azure - есть регионы в России, но Azure в апреле 2020 тоже сидит под нагрузкой, сроки развёртывания managed-сервисов плавали. Mail.ru Cloud Solutions рассматривали, но поддержка и документация на тот момент оставляли вопросы. Yandex Cloud - понятная документация на русском, нормальная поддержка, managed-сервисы для PostgreSQL и Object Storage есть и уже в рабочем состоянии. Остановились на нём.

Что переезжало в первой волне

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

Сеть и периметр. Первым делом - VPC, подсети, группы безопасности. Разделили окружения: production и test сразу в разные подсети, не в одну плоскую. Это требование не из учебника, а из личного опыта - потом разделять больнее. NAT-шлюз для исходящего трафика, VPN-туннель site-to-site между облаком и офисом (пока сохранили часть сервисов on-premise). Туннель подняли через Yandex Cloud VPN на стандартных IPsec-параметрах - работает стабильно, хотя управление маршрутизацией через консоль достаточно ручное.

IAM и сервисные аккаунты. Здесь самая неприятная часть для клиентов, которые раньше не работали с облаком: непривычная модель прав. В Yandex Cloud роли назначаются на уровне организации, облака, каталога и конкретного ресурса. Потратили несколько часов на объяснение почему нельзя просто дать всем «администратора» и быть счастливыми. Разграничили: разработчики - права на конкретный каталог, devops - шире, но не на всё, финансы - только просмотр биллинга. Сервисные аккаунты для CI/CD с отдельными ключами, ротация - ручная пока, автоматизацию отложили на следующую итерацию.

Виртуальные машины. Lift-and-shift в буквальном смысле: взяли образы с on-premise (где были VMware VMDK), конвертировали через qemu-img в raw/qcow2, загрузили в Object Storage, создали образы в Compute Cloud. Не всё прошло с первой попытки - несколько машин требовали дополнительных драйверов virtio и правки /etc/fstab. Ничего критичного, но время уходит именно на это.

Object Storage. Файловый сервер - больная точка. 4 ТБ файлов, к которым нужен доступ у всех. Перенесли в Object Storage, смонтировали через s3fs на терминальных серверах. Честно скажем: s3fs - решение рабочее, но не идеальное. На больших каталогах листинг медленный, кеширование требует настройки. Для активно редактируемых файлов это решение создаёт трение - пользователи замечают задержки при сохранении. Параллельно смотрим на Yandex Managed File Storage, но он ещё не в общей доступности на момент миграции.

Мониторинг. Yandex Cloud Monitoring интегрирован в консоль, метрики с виртуальных машин идут автоматически если поставить агент. Настроили алёрты на CPU, диск, доступность по HTTP. Для прикладного мониторинга поверх оставили Zabbix - клиент с ним знаком, переучивать людей не было смысла в этот момент. Экспорт метрик из Yandex Monitoring во внешний источник через API возможен, но требует небольшой самописной обвязки.

Что не поехало в первой волне

База данных. PostgreSQL пока остался on-premise. Не потому что принципиально против - просто переезд БД требует тщательного плана: окно миграции, репликация, тестирование, откат. За две недели в правильном режиме это не делается. Managed Service for PostgreSQL в Yandex Cloud присмотрели, сделаем отдельным проектом.

Старый Windows-сервис. Один из внутренних сервисов работает на Windows Server 2008 R2 и неизвестно как соберётся на другом железе. Это отдельная история, трогать в авральном режиме - плохая идея. Оставили за NAT-туннелем.

Что получили на выходе

Через две недели основная часть сотрудников работает через облачные ресурсы. VPN-проблема решилась не через апгрейд шлюза, а через то, что терминальные серверы теперь в облаке и доступны без VPN через RD Gateway (отдельный пост про это был в марте). Файловый сервер работает, с оговорками. БД на удалёнке через туннель - терпимо, но это временно.

Стоимость облака в первый месяц оказалась выше прогноза - не учли трафик между зонами и стоимость snapshot'ов. После оптимизации профиля машин (несколько сервисов запускали с избыточным числом vCPU «на всякий случай») счёт стал предсказуемее.

Общий вывод по первой волне

Lift-and-shift - это быстро, но не бесплатно по техническому долгу. Всё что не перепроектировалось под облако едет в облако с теми же проблемами что были на железе - просто теперь за это платишь помесячно. Объектное хранилище вместо NFS - не одно и то же, и пользователи это чувствуют. IAM в облаке строже чем «кто в домене, тот имеет доступ», и это правильно, но требует времени на принятие.

В managed-сопровождение таких переездов за апрель уже три. Спрос понятен: Yandex Cloud и другие провайдеры фиксируют кратный рост подключений в марте-апреле. Мы видим это по потоку запросов. Переезжают не потому что модно, а потому что on-premise не держит нагрузку прямо сейчас, а арендовать дополнительное железо в ЦОД в апреле 2020 занимает месяц.