Зачем CarPrice понадобился переезд?

В конце 2021-го года мы фиксировали высокую загруженность аппаратных ресурсов: для продолжения нормальной работы требовалось увеличение мощностей. Вопрос был в том, как именно мы будем расширяться — арендуем новые серверы в «родном» ЦОДе или уйдем на новую платформу.

Сделать выбор в пользу нового дата-центра нас убедили несколько факторов: 

• Во-первых, мы получили более выгодное предложение по аренде оборудования. 

• Во-вторых, аппаратные характеристики оборудования в рамках этого предложения оптимально подходили для наших задач.

Здесь стоит сделать шаг назад и вспомнить, по какой схеме дата-центры обычно предоставляют компаниям оборудование. Все обстоит примерно так: молодой стартап арендует у ЦОД пару серверов, затем, если у него получилось вырасти, арендует еще и еще. При этом характеристики новых серверов могут не совпадать с предыдущими.

Мы к концу 2021-го арендовали несколько десятков разношерстных серверов. При этом их производительности в очередной раз становилось недостаточно. Аппаратное преимущество нового комплекта оборудования как раз заключалось в том, что мы меняли разрозненные серверы на типовые блейды HP, плюс получали быструю сеть 10 Гбит/с против текущего одного гигабита. Стоит отметить, что сеть в 10 Гбит/с мы могли получить за дополнительную плату и в текущем дата-центре, но это не закрывало все накопившиеся потребности.

• В-третьих, обновления требовало не только железо — мы давно планировали оптимизацию архитектуры. За годы работы она обросла элементами, до которых у сотрудников не доходят руки: возможность поработать над этим стала приятным бонусом переезда.

Немного о том, куда мы переехали

Упомянутое предложение мы получили от платформы Scaled.cloud. Оператор предоставляет услуги хостинга, аренды оборудования или частного облака в дата-центрах, расположенных в крупных городах по выбору заказчика. 

Ключевые особенности Scaled.cloud:

• Законченное решение. Платформа предоставляет как частное облако на базе OpenStack, так и bare-metal платформы, на которых заказчик может сам развернуть гипервизор и сопутствующие сервисы.

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

• Самостоятельное и оперативное управление вверенным инфраструктурным окружением, всеми доступными типами виртуальных ресурсов и резервными копиями в случае выбора OpenStack.

• Техническая поддержка при миграции сервисов из различных форматов образов и платформ виртуализации в OpenStack.

• Мониторинг. Детальные отчеты по использованию ресурсов со всеми возможными группировками данных позволяют отслеживать и использовать информацию для оптимального планирования ресурсов и затрат.

Так как мы и ранее использовали dedicated серверы и управляли железом самостоятельно, в предложении Scaled.cloud нас привлекла возможность получить набор оборудования, который наилучшим образом подходит под наши запросы.

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

Формулировка требований к переезду

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

1. Даунтайм нужно минимизировать. 

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

2. Переезд важно сделать бесшовным. Так как за одну ночь переезд осуществить невозможно, старые и новые серверы должны работать одновременно для плавной миграции сервисов.

3.  Перенос нагрузки из одного ДЦ в другой необходимо осуществлять в соответствии с имеющейся пропускной способностью интернет-канала в обоих дата-центрах. Работы по переносу данных между датацентрами не должны влиять на продуктовый трафик.

4. Переезд нужно осуществить за 2 месяца с момента сдачи оборудования в новом дата-центре — иначе придется платить за оба ЦОДа.

Обязательно формулируйте высокоуровневые требования к переезду. Иначе есть риск не учесть что-то важное для бизнеса. 

Планирование работ

Детальное планирование каждого этапа работ — очень важный этап переезда. Без четкого плана в работе быстро наступит хаос: сотрудники начнут хвататься за разные задачи. А последовательность действий часто имеет решающее значение. Процессы внутри переезда разворачиваются стремительно — даже самым опытным разработчикам и инженерам сложно импровизировать в таких условиях.

Кроме того, при переезде важно учесть все инфраструктурные особенности — тут план тоже может быть хорошим помощником, который позволит не упустить небольшие детали. Мы, например, приверженцы CI/СD — наша архитектура включает в себя большое количество виртуальных машин и развернутых Docker-контейнеров. Это облегчает переезд, но требует аккуратной работы с первоначальными настройками и соблюдения определенной последовательности действий.

Чтобы уложиться в сроки и учесть все детали, мы составили план переезда в виде диаграммы Ганта.

Наконец, именно планирование может стать надежной основой для обновления инфраструктуры. За годы работы она обрастает ненужными или малоэффективными элементами — подготовка плана становится отличным поводом разобраться с ними.

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

Этапы переезда

Примерную схему наших работ в рамках переезда можно представить следующим образом:

Шаги первого этапа:

• Подготовка целевой схемы архитектуры;

• Планирование сети и адресного плана;

• Получение доступа к новой инфраструктуре, ознакомление с документацией и интерфейсами управления.

Шаги второго этапа:

• Запуск и подготовка гипервизора на новом оборудовании;

• Настройка маршрутизации между старым и новым ЦОД;

• Запуск и настройка базовых компонентов инфраструктуры (роутеры, DNS-серверы, etc); 

• Подготовка кластеров Kubernetes.

Шаги третьего этапа:

• Миграция dev-окружений;

• Анализ работы инфраструктуры после переезда dev-серверов и корректировки для prod-окружения.

Шаги четвертого этапа: 

• Миграция docker-сервисов;

• Миграция баз данных;

• Миграция микросервисов в новый кластер Kubernetes;

• Миграция компонентов мониторинга.

Шаги пятого этапа:

• Отладка работы инфраструктуры и сервисов после переезда;

• Анализ показателей мониторинга и внесение корректировок.

Когда все идет не по плану: переезд и гибкость

Когда план составлен, все выглядит последовательно и логично — но реальный переезд, конечно, не обошелся без происшествий, небольших корректировок и дополнений изначального плана. 

Во время нашего переезда самым крупным был инцидент после миграции мастера и слейва базы данных на серверы в новой инфраструктуре. Данный процесс требовал изменения настроек DNS, а также файлов конфигурации для всех приложений, которые обращаются к базе данных. Настройки производились как посредством изменений конфигурации в gitlab с последующей «раскаткой» через CI/CD, так и непосредственной корректировкой конфигурационных файлов в случае старого монолита (да, и такое, к сожалению, еще сохранилось). 

К моменту окончания работ по миграции все настройки и в gitlab и в файлах на серверах монолита были скорректированы, приложение находилось в работоспособном состоянии. Однако мы не учли один момент: часть настроек монолита хранились и в gitlab тоже, но применялась на серверах через CI/CD каждый раз при деплое приложения. 

Из-за этого утром, когда разработчики вышли на работу, и состоялся первый деплой в монолит, на сервер «заехали» старые настройки подключения к БД с вытекающей неработоспособностью сервиса.

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

1. Обязательно составляйте план работ перед их выполнением (было сделано);

2. Тщательно расписывайте в плане работ все операции, которые требуется выполнить для корректной перенастройки системы (в нашем случае в плане работ был пункт об изменении настроек для приложения монолита, но не были достаточно подробно расписаны операции);

3. Выполняйте перекрестные проверки (review) плана изменения настроек системы. В том числе с привлечением представителей отдела разработки, если изменение настроек касается продуктовых приложений;

4. Стройте архитектуру так, чтобы уменьшить количество конфигурационных файлов, в которые нужно внести изменения при смене реквизитов какого-либо компонента системы. Это может быть достигнуто, например, с использованием общего хранилища конфигураций, которые вызываются при деплое приложения (например, Hashicorp Consul или Vault);

5. Все критичные изменения производите во время наименьшей нагрузки (в нашем случае это была ночь) с оповещением о работах всех потенциально задействованных лиц. Даже если что-то пойдет не по плану, в часы наименьшей нагрузки можно выделить больше времени на анализ и грамотное решение проблемы.

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

Что в итоге?

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

Вот основные компоненты нашей новой аппаратной платформы:

• Серверные шасси: HP BladeSystem C9000;

• Типовая конфигурация серверов: 64 vCPU, 192 или 256 GB RAM;

• Дисковые хранилища:

• IBM All Flash 900 Raid SAN Storage 9843-AE2 для быстрых дисков;

• Dell MD3200i для холодных данных;

• Сеть: 10 Гбит/с.

В результате мы довольны втройне — и новым железом, и ростом производительности, и проведенной оптимизацией.

• В результате переезда мы перешли с набора разношерстных серверов на блейд-платформу HP BladeSystem C9000.

• Если сравнивать с предыдущем оборудованием, то мы получили суммарный рост аппаратных ресурсов CPU и RAM на 40-50%. Производительность сети увеличили с 1 гигабита до 10. Диски, которые мы «нарезаем» для виртуальных машин, также стали значительно быстрее — за счёт all-flash хранилища.

• Благодаря детальному планированию нам удалось оптимизировать множество конфигураций и политик. В том числе тех, до которых давно не доходили руки.

• В ходе работ мы добавили дополнительные правила мониторинга.

• В процессе переезда сформировали новые задачи по развитию нашей инфраструктуры.

Впрочем, все самое интересное — впереди: после переезда у нас много амбициозных планов. И мы всегда рады новым коллегам и единомышленникам на этом пути :)