Срочный переезд с Amazon Web Services — истории двух клиентов
Блокировки задели многие проекты, работающие для российского рынка. Ниже — история одного из срочных переездов нашего заказчика.
19 апреля они заметили блокировку одного из IP-адресов своего публичного сервиса частью провайдеров на территории РФ. 20 апреля ситуация усугубилась — вся подсеть стала недоступной. Это уронило тестовую среду, один из резервных каналов, частично нарушило работу почтовых серверов. Проблему удалось решить заменой IP-адресов, проксированием трафика через другие дата-центры.
Когда стало понятно, что всё это всерьёз и надолго (точнее, когда возник такой риск), один наш заказчик, компания Теко — международная процессинговая компания, решил развернуть инстанс в нашем облаке. Их CIO была важна большая федеративность сервиса, большее присутствие на территории РФ. Цитата:
«Облако в РФ даёт больше гарантий клиентам, что сервис не будет заблокирован РКН. Скорость, с которой нам предоставили ресурсы, была очень важна. Происходило всё достаточно быстро: первым делом мы добавили GEO dns для доступности сервиса на территории РФ, начали проксирование трафика через незаблокированные ДЦ. Медленная часть — федерация для БД».
«Были сложности с технологическим стэком, который мы используем, необходимо было строить дополнительные туннели до зарубежного облака, столкнулись с проблемой в работе новых версий strongSwan… Во сколько обошлось? Очень дорого: помимо прямой оплаты за вычислительные ресурсы, есть существенные траты временных ресурсов на поддержку нескольких облаков, отсутствие необходимых амазоновских/гугловских услуг. В итоге работаем с дополнительным облаком, несём гораздо большие финансовые расходы. Появились дополнительные точки отказа. Диагностика проблем стала сложнее. Мы используем подход IaC (infrastructure as code), это позволило построить воспроизводимую инфраструктуру на базе Terraform, Ansible, Kubernetes. Деплой инфраструктуры достаточно быстро проходил».
Вторая история
«Заметили, как и все, — из новостей. Перестали работать или стали работать со сбоями некоторые сторонние сервисы, которые мы используем в своей работе. Например, Slack и Maven-репозитории. Непосредственно нашего бизнеса это не затронуло — мы уже достаточно давно держим инфраструктуру, которая обслуживает клиентов в РФ, у провайдеров в РФ. С облаком Техносерв мы знакомы уже достаточно давно и накопили некоторые знания о нём.
При выборе облачного провайдера, помимо качества и надёжности сервиса, важны юридические вопросы. Документооборот в случае облака вне РФ достаточно сложный, оплата сопряжена с валютным контролем и налоговыми тонкостями. Если компания работает и ведёт бизнес в РФ, то проще всего иметь всю обслуживающую его инфраструктуру там же.
Мы работали с разными провайдерами в РФ, также у нашей команды большой опыт работы с платформой AWS и другими мировыми лидерами в IaaS. От облачного провайдера мы ожидаем не просто возможность арендовать виртуальную машину, а дополнительный функционал, который позволит упростить поддержку инфраструктуры, такой как:
- облачные хранилища и базы данных, которые позволяют экономить на самостоятельной поддержке сложных решений. При этом важно, чтобы они были построены на основе индустриальных стандартов, а не приводили к vendor-lock;
- гибкое ценообразование, которое учитывает особенности нашего использования вычислительных ресурсов, позволяет нам действительно экономить. Важен подход провайдера, его готовность совместно с клиентом искать способы оптимизации;
- удобные инструменты управления инфраструктурой — работать с самописной панелью управления без API не всегда бывает удобно.
В случае Техносерва весь перечисленный функционал мы увидели, это стало для нас важным аргументом. Дальнейшее тестирование показало большой запас по производительности инфраструктуры Техносерв и желание технической службы идти навстречу и отлаживать вместе узкие места инфраструктуры, которые в итоге перестали таковыми быть. Мы мигрировали в него несколько сервисов из других облачных провайдеров, далее стали новые сервисы развёртывать уже в облаке Техносерв.
У нас заняло около месяца разобраться с облачным хранилищем и встроить новую площадку в нашу существующую сетевую инфраструктуру.
Были проблемы при интеграции облачного хранилища, возможно, мы были первыми, кто его использовал в такой модели. Однако мы остались довольны работой с поддержкой: коллеги помогли нам решить основные проблемы, по необходимости подключили разработчиков хранилища для исправления ошибок.
В итоге получили площадку, которая стала основной для нас в РФ. Мы подключили ряд инструментов, которые мы используем для обработки данных, такие как Apache Spark и Apache Zeppelin, к работе с облачным хранилищем Техносерв. Мы были приятно удивлены, что полная совместимость с AWS S3 API позволяет использовать существующие библиотеки без каких-либо изменений. В случае со Spark использование облачного хранилища для нас позволяет избежать необходимости в HDFS-кластерах и экономить на этом деньги, при этом не теряя в скорости и надёжности».
Что происходит?
Из-за блокировок началась вторая волна миграции с Амазона на российские облака (первая волна была в момент начала действия новых нормативов по хранению и обработке персональных данных, она, по сути, дала толчок российскому рынку виртуализации). Большинству наших новых заказчиков нужны максимально совместимые сервисы вроде объектного хранилища S3. В России только четыре облачных провайдера поставляют эту услугу и мы наиболее совместимы по оценке экспертов (надо отметить, оценка делалась, когда S3-провайдеров было три) — CIO выбирают нашу площадку.
Почему не VPN или проксирование? Потому что поддерживать стабильно такую структуру достаточно сложно в свете тех же блокировок. Некоторые заказчики рассматривали варианты переноса инфраструктуры на немецкие сервера, но, как вы знаете, это оперативное решение не помогло — те же Hetzner попали в список блокировок сразу всей подсетью.
Итог — переноситься в российское облако. Причина довольно банальна: поскольку Роскомнадзор — российская организация, на территории РФ он сначала предупреждает о блокировке, потом даёт время принять меры, потом блокирует. То есть мы можем либо выделить «хулиганам» подсеть, блокировка которой не коснётся остальных клиентов, либо попросить их прекратить деятельность по пункту о помехах другим клиентам публичного облака.
У нас открытые цены, при определённых условиях мы выгоднее Амазона. Вот прайс.
«Кошмарить» физически нас не начнут в силу ряда причин организационного характера — нужно судебное постановление, которое довольно долго получается. Но про это лучше расскажет мой коллега чуть позже.
Поскольку у нас довольно гибкое квантование, если ситуация прекратится, можно будет переключиться обратно на AWS и держать у нас договор для резервного развёртывания. Если не прекратится — ну, есть российский ЦОД, где крутится Амазон-совместимое облако. Мы помогаем переехать быстро и подняться с минимальным даунтаймом или без него — в зависимости от архитектуры и объёмов.
Самый частый случай переезда некрупных проектов сейчас — либо бекап, остановка и развёртывание из бекапа у нас, либо бекап, развёртывание, синхронизация и отключение первого инстанса.
По всем вопросам пишите на почту: MBlinov@technoserv.com
