Зачем CarPrice понадобился переезд?
В конце 2021-го года мы фиксировали высокую загруженность аппаратных ресурсов: для продолжения нормальной работы требовалось увеличение мощностей. Вопрос был в том, как именно мы будем расширяться — арендуем новые серверы в «родном» ЦОДе или уйдем на новую платформу.
Сделать выбор в пользу нового дата-центра нас убедили несколько факторов:
Во-первых, мы получили более выгодное предложение по аренде оборудования.
Во-вторых, аппаратные характеристики оборудования в рамках этого предложения оптимально подходили для наших задач.
Здесь стоит сделать шаг назад и вспомнить, по какой схеме дата-центры обычно предоставляют компаниям оборудование. Все обстоит примерно так: молодой стартап арендует у ЦОД пару серверов, затем, если у него получилось вырасти, арендует еще и еще. При этом характеристики новых серверов могут не совпадать с предыдущими.
Мы к концу 2021-го арендовали несколько десятков разношерстных серверов. При этом их производительности в очередной раз становилось недостаточно. Аппаратное преимущество нового комплекта оборудования как раз заключалось в том, что мы меняли разрозненные серверы на типовые блейды HP, плюс получали быструю сеть 10 Гбит/с против текущего одного гигабита. Стоит отметить, что сеть в 10 Гбит/с мы могли получить за дополнительную плату и в текущем дата-центре, но это не закрывало все накопившиеся потребности.
В-третьих, обновления требовало не только железо — мы давно планировали оптимизацию архитектуры. За годы работы она обросла элементами, до которых у сотрудников не доходят руки: возможность поработать над этим стала приятным бонусом переезда.
Немного о том, куда мы переехали
Упомянутое предложение мы получили от платформы Scaled.cloud. Оператор предоставляет услуги хостинга, аренды оборудования или частного облака в дата-центрах, расположенных в крупных городах по выбору заказчика.
![](https://habrastorage.org/getpro/habr/upload_files/3f3/184/210/3f3184210bd0c61a8d4a564778cb130d.png)
Ключевые особенности Scaled.cloud:
Законченное решение. Платформа предоставляет как частное облако на базе OpenStack, так и bare-metal платформы, на которых заказчик может сам развернуть гипервизор и сопутствующие сервисы.
Надежность. Серверы, дисковые тома, сети, коммутаторы и маршрутизаторы, брандмауэры, балансировщики нагрузки, общие файловые ресурсы и даже базы данных находятся в отказоустойчивой среде. Хранилища данных одновременно доступны через пару резервных контроллеров. Серверные шасси имеют несколько блоков питания и резервные управляющие модули.
Самостоятельное и оперативное управление вверенным инфраструктурным окружением, всеми доступными типами виртуальных ресурсов и резервными копиями в случае выбора OpenStack.
Техническая поддержка при миграции сервисов из различных форматов образов и платформ виртуализации в OpenStack.
Мониторинг. Детальные отчеты по использованию ресурсов со всеми возможными группировками данных позволяют отслеживать и использовать информацию для оптимального планирования ресурсов и затрат.
Так как мы и ранее использовали dedicated серверы и управляли железом самостоятельно, в предложении Scaled.cloud нас привлекла возможность получить набор оборудования, который наилучшим образом подходит под наши запросы.
Также Scaled.cloud полностью брала на себя обслуживание, мониторинг и реагирование на инциденты по железу и сети. Наша зона ответственности начиналась с операционных систем, устанавливаемых на серверы.
![В качестве дата-центра, в котором будет располагаться оборудование, мы выбрали ДЦ «Миран» в Санкт-Петербурге.Так выглядели новые стойки CarPrice на момент монтажа В качестве дата-центра, в котором будет располагаться оборудование, мы выбрали ДЦ «Миран» в Санкт-Петербурге.Так выглядели новые стойки CarPrice на момент монтажа](https://habrastorage.org/getpro/habr/upload_files/82a/9d7/d1b/82a9d7d1b24341fe9ce94f87e2d96f4a.png)
Формулировка требований к переезду
![](https://habrastorage.org/getpro/habr/upload_files/01e/31a/8ce/01e31a8ce518a83bfddbf905ac2cc062.jpg)
Приняв решение о переезде, мы приступили к планированию. Прежде всего, сформулировали внутренние требования, необходимые для соблюдения интересов бизнеса:
Даунтайм нужно минимизировать.
Все работы по переезду были назначены на ночное время, так что критически важные для бизнеса сервисы получилось перевести в часы наименьшей нагрузки. Ни один запланированный простой не пришелся на время проведения онлайн-аукциона.
Переезд важно сделать бесшовным. Так как за одну ночь переезд осуществить невозможно, старые и новые серверы должны работать одновременно для плавной миграции сервисов.
Перенос нагрузки из одного ДЦ в другой необходимо осуществлять в соответствии с имеющейся пропускной способностью интернет-канала в обоих дата-центрах. Работы по переносу данных между датацентрами не должны влиять на продуктовый трафик.
Переезд нужно осуществить за 2 месяца с момента сдачи оборудования в новом дата-центре — иначе придется платить за оба ЦОДа.
Обязательно формулируйте высокоуровневые требования к переезду. Иначе есть риск не учесть что-то важное для бизнеса.
Планирование работ
Детальное планирование каждого этапа работ — очень важный этап переезда. Без четкого плана в работе быстро наступит хаос: сотрудники начнут хвататься за разные задачи. А последовательность действий часто имеет решающее значение. Процессы внутри переезда разворачиваются стремительно — даже самым опытным разработчикам и инженерам сложно импровизировать в таких условиях.
Кроме того, при переезде важно учесть все инфраструктурные особенности — тут план тоже может быть хорошим помощником, который позволит не упустить небольшие детали. Мы, например, приверженцы CI/СD — наша архитектура включает в себя большое количество виртуальных машин и развернутых Docker-контейнеров. Это облегчает переезд, но требует аккуратной работы с первоначальными настройками и соблюдения определенной последовательности действий.
Чтобы уложиться в сроки и учесть все детали, мы составили план переезда в виде диаграммы Ганта.
![](https://habrastorage.org/getpro/habr/upload_files/e4c/718/e0f/e4c718e0fbfc71b350660fbaf9f7aef5.jpg)
Наконец, именно планирование может стать надежной основой для обновления инфраструктуры. За годы работы она обрастает ненужными или малоэффективными элементами — подготовка плана становится отличным поводом разобраться с ними.
Переезд — подходящее время чтобы переосмыслить текущую инфраструктуру и продумать ее оптимизацию. Спланируйте архитектуру, удалите все ненужное, обновите конфигурации. Зафиксируйте недостатки в текущих компонентах и поищите альтернативные решения. Мы, например, именно во время переезда запланировали переход на новую схему работы с dev окружением и несколько важных шагов по развитию системы мониторинга.
Этапы переезда
Примерную схему наших работ в рамках переезда можно представить следующим образом:
Шаги первого этапа:
Подготовка целевой схемы архитектуры;
Планирование сети и адресного плана;
Получение доступа к новой инфраструктуре, ознакомление с документацией и интерфейсами управления.
Шаги второго этапа:
Запуск и подготовка гипервизора на новом оборудовании;
Настройка маршрутизации между старым и новым ЦОД;
Запуск и настройка базовых компонентов инфраструктуры (роутеры, DNS-серверы, etc);
Подготовка кластеров Kubernetes.
Шаги третьего этапа:
Миграция dev-окружений;
Анализ работы инфраструктуры после переезда dev-серверов и корректировки для prod-окружения.
Шаги четвертого этапа:
Миграция docker-сервисов;
Миграция баз данных;
Миграция микросервисов в новый кластер Kubernetes;
Миграция компонентов мониторинга.
Шаги пятого этапа:
Отладка работы инфраструктуры и сервисов после переезда;
Анализ показателей мониторинга и внесение корректировок.
![](https://habrastorage.org/getpro/habr/upload_files/2ea/c49/0ee/2eac490ee4f239fbfe580aae470e5f37.jpg)
Когда все идет не по плану: переезд и гибкость
Когда план составлен, все выглядит последовательно и логично — но реальный переезд, конечно, не обошелся без происшествий, небольших корректировок и дополнений изначального плана.
Во время нашего переезда самым крупным был инцидент после миграции мастера и слейва базы данных на серверы в новой инфраструктуре. Данный процесс требовал изменения настроек DNS, а также файлов конфигурации для всех приложений, которые обращаются к базе данных. Настройки производились как посредством изменений конфигурации в gitlab с последующей «раскаткой» через CI/CD, так и непосредственной корректировкой конфигурационных файлов в случае старого монолита (да, и такое, к сожалению, еще сохранилось).
К моменту окончания работ по миграции все настройки и в gitlab и в файлах на серверах монолита были скорректированы, приложение находилось в работоспособном состоянии. Однако мы не учли один момент: часть настроек монолита хранились и в gitlab тоже, но применялась на серверах через CI/CD каждый раз при деплое приложения.
Из-за этого утром, когда разработчики вышли на работу, и состоялся первый деплой в монолит, на сервер «заехали» старые настройки подключения к БД с вытекающей неработоспособностью сервиса.
Все достаточно быстро сориентировались, разбудили людей, которые выполняли работы, совместно разобрались, в чем дело, и внесли исправления. Но определенный простой в работе критически важных production-сервисов мы получили. Вместе с этим получили и опыт, из которого извлекли следующие выводы:
Обязательно составляйте план работ перед их выполнением (было сделано);
Тщательно расписывайте в плане работ все операции, которые требуется выполнить для корректной перенастройки системы (в нашем случае в плане работ был пункт об изменении настроек для приложения монолита, но не были достаточно подробно расписаны операции);
Выполняйте перекрестные проверки (review) плана изменения настроек системы. В том числе с привлечением представителей отдела разработки, если изменение настроек касается продуктовых приложений;
Стройте архитектуру так, чтобы уменьшить количество конфигурационных файлов, в которые нужно внести изменения при смене реквизитов какого-либо компонента системы. Это может быть достигнуто, например, с использованием общего хранилища конфигураций, которые вызываются при деплое приложения (например, Hashicorp Consul или Vault);
Все критичные изменения производите во время наименьшей нагрузки (в нашем случае это была ночь) с оповещением о работах всех потенциально задействованных лиц. Даже если что-то пойдет не по плану, в часы наименьшей нагрузки можно выделить больше времени на анализ и грамотное решение проблемы.
В общем, придерживайтесь плана, но никогда не теряйте гибкости и не забывайте про инструменты тестирования и мониторинга. Если что-то пойдет не так, они помогут оперативно выявить ошибку и внести в расписание работ все необходимые изменения.
Что в итоге?
![](https://habrastorage.org/getpro/habr/upload_files/c91/b06/17d/c91b0617d325d6c7a63082f4c306af0d.png)
Обычно переезд сравнивают с головной болью и пожаром. Но мы подходили к нему постепенно и осознанно — и успешно запустились на новом оборудовании. А еще в процессе работ посмотрели на собственную архитектуру свежим взглядом и внесли необходимые корректировки и оптимизации.
Вот основные компоненты нашей новой аппаратной платформы:
Серверные шасси: 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 хранилища.
Благодаря детальному планированию нам удалось оптимизировать множество конфигураций и политик. В том числе тех, до которых давно не доходили руки.
В ходе работ мы добавили дополнительные правила мониторинга.
В процессе переезда сформировали новые задачи по развитию нашей инфраструктуры.
Впрочем, все самое интересное — впереди: после переезда у нас много амбициозных планов. И мы всегда рады новым коллегам и единомышленникам на этом пути :)