В конце 2021-го года мы фиксировали высокую загруженность аппаратных ресурсов: для продолжения нормальной работы требовалось увеличение мощностей. Вопрос был в том, как именно мы будем расширяться — арендуем новые серверы в «родном» ЦОДе или уйдем на новую платформу. Сделать выбор в пользу нового дата-центра нас убедили несколько факторов:  Во-первых, мы получили более выгодное предложение по аренде оборудования.  Во-вторых, аппаратные характеристики оборудования в рамках этого предложения оптимально подходили для наших задач. Здесь стоит сделать шаг назад и вспомнить, по какой схеме дата-центры обычно предоставляют компаниям оборудование. Все обстоит примерно так: молодой стартап арендует у ЦОД пару серверов, затем, если у него получилось вырасти, арендует еще и еще. При этом характеристики новых серверов могут не совпадать с предыдущими. Мы к концу 2021-го арендовали несколько десятков разношерстных серверов. При этом их производительности в очередной раз становилось недостаточно. Аппаратное преимущество нового комплекта оборудования как раз заключалось в том, что мы меняли разрозненные серверы на типовые блейды HP, плюс получали быструю сеть 10 Гбит/с против текущего одного гигабита. Стоит отметить, что сеть в 10 Гбит/с мы могли получить за дополнительную плату и в текущем дата-центре, но это не закрывало все накопившиеся потребности. В-третьих, обновления требовало не только железо — мы давно планировали оптимизацию архитектуры. За годы работы она обросла элементами, до которых у сотрудников не доходят руки: возможность поработать над этим стала приятным бонусом переезда. Упомянутое предложение мы получили от платформы Scaled.cloud. Оператор предоставляет услуги хостинга, аренды оборудования или частного облака в дата-центрах, расположенных в крупных городах по выбору заказчика.  Ключевые особенности Scaled.cloud: Законченное решение. Платформа предоставляет как частное облако на базе OpenStack, так и bare-metal платформы, на которых заказчик может сам развернуть гипервизор и сопутствующие сервисы. Надежность. Серверы, дисковые тома, сети, коммутаторы и маршрутизаторы, брандмауэры, балансировщики нагрузки, общие файловые ресурсы и даже базы данных находятся в отказоустойчивой среде. Хранилища данных одновременно доступны через пару резервных контроллеров. Серверные шасси имеют несколько блоков питания и резервные управляющие модули. Самостоятельное и оперативное управление вверенным инфраструктурным окружением, всеми доступными типами виртуальных ресурсов и резервными копиями в случае выбора OpenStack. Техническая поддержка при миграции сервисов из различных форматов образов и платформ виртуализации в OpenStack. Мониторинг. Детальные отчеты по использованию ресурсов со всеми возможными группировками данных позволяют отслеживать и использовать информацию для оптимального планирования ресурсов и затрат. Так как мы и ранее использовали dedicated серверы и управляли железом самостоятельно, в предложении Scaled.cloud нас привлекла возможность получить набор оборудования, который наилучшим образом подходит под наши запросы. Также Scaled.cloud полностью брала на себя обслуживание, мониторинг и реагирование на инциденты по железу и сети. Наша зона ответственности начиналась с операционных систем, устанавливаемых на серверы. Приняв решение о переезде, мы приступили к планированию. Прежде всего, сформулировали внутренние требования, необходимые для соблюдения интересов бизнеса:  Даунтайм нужно минимизировать.  Все работы по переезду были назначены на ночное время, так что критически важные для бизнеса сервисы получилось перевести в часы наименьшей нагрузки. Ни один запланированный простой не пришелся на время проведения онлайн-аукциона. Переезд важно сделать бесшовным. Так как за одну ночь переезд осуществить невозможно, старые и новые серверы должны работать одновременно для плавной миграции сервисов.  Перенос нагрузки из одного ДЦ в другой необходимо осуществлять в соответствии с имеющейся пропускной способностью интернет-канала в обоих дата-центрах. Работы по переносу данных между датацентрами не должны влиять на продуктовый трафик. Переезд нужно осуществить за 2 месяца с момента сдачи оборудования в новом дата-центре — иначе придется платить за оба ЦОДа. Обязательно формулируйте высокоуровневые требования к переезду. Иначе есть риск не учесть что-то важное для бизнеса.  Детальное планирование каждого этапа работ — очень важный этап переезда. Без четкого плана в работе быстро наступит хаос: сотрудники начнут хвататься за разные задачи. А последовательность действий часто имеет решающее значение. Процессы внутри переезда разворачиваются стремительно — даже самым опытным разработчикам и инженерам сложно импровизировать в таких условиях. Кроме того, при переезде важно учесть все инфраструктурные особенности — тут план тоже может быть хорошим помощником, который позволит не упустить небольшие детали. Мы, например, приверженцы CI/СD — наша архитектура включает в себя большое количество виртуальных машин и развернутых Docker-контейнеров. Это облегчает переезд, но требует аккуратной работы с первоначальными настройками и соблюдения определенной последовательности действий. Чтобы уложиться в сроки и учесть все детали, мы составили план переезда в виде диаграммы Ганта. Наконец, именно планирование может стать надежной основой для обновления инфраструктуры. За годы работы она обрастает ненужными или малоэффективными элементами — подготовка плана становится отличным поводом разобраться с ними. Переезд — подходящее время чтобы переосмыслить текущую инфраструктуру и продумать ее оптимизацию. Спланируйте архитектуру, удалите все ненужное, обновите конфигурации. Зафиксируйте недостатки в текущих компонентах и поищите альтернативные решения. Мы, например, именно во время переезда запланировали переход на новую схему работы с dev окружением и несколько важных шагов по развитию системы мониторинга. Примерную схему наших работ в рамках переезда можно представить следующим образом: Шаги первого этапа: Подготовка целевой схемы архитектуры; Планирование сети и адресного плана; Получение доступа к новой инфраструктуре, ознакомление с документацией и интерфейсами управления. Шаги второго этапа:  Запуск и подготовка гипервизора на новом оборудовании; Настройка маршрутизации между старым и новым ЦОД; Запуск и настройка базовых компонентов инфраструктуры (роутеры, DNS-серверы, etc);  Подготовка кластеров Kubernetes. Шаги третьего этапа: Миграция dev-окружений; Анализ работы инфраструктуры после переезда dev-серверов и корректировки для prod-окружения. Шаги четвертого этапа:  Миграция docker-сервисов; Миграция баз данных; Миграция микросервисов в новый кластер Kubernetes; Миграция компонентов мониторинга. Шаги пятого этапа: Отладка работы инфраструктуры и сервисов после переезда; Анализ показателей мониторинга и внесение корректировок. Когда план составлен, все выглядит последовательно и логично — но реальный переезд, конечно, не обошелся без происшествий, небольших корректировок и дополнений изначального плана.  Во время нашего переезда самым крупным был инцидент после миграции мастера и слейва базы данных на серверы в новой инфраструктуре. Данный процесс требовал изменения настроек DNS, а также файлов конфигурации для всех приложений, которые обращаются к базе данных. Настройки производились как посредством изменений конфигурации в gitlab с последующей «раскаткой» через CI/CD, так и непосредственной корректировкой конфигурационных файлов в случае старого монолита (да, и такое, к сожалению, еще сохранилось).  К моменту окончания работ по миграции все настройки и в gitlab и в файлах на серверах монолита были скорректированы, приложение находилось в работоспособном состоянии. Однако мы не учли один момент: часть настроек монолита хранились и в gitlab тоже, но применялась на серверах через CI/CD каждый раз при деплое приложения.  Из-за этого утром, когда разработчики вышли на работу, и состоялся первый деплой в монолит, на сервер «заехали» старые настройки подключения к БД с вытекающей неработоспособностью сервиса. Все достаточно быстро сориентировались, разбудили людей, которые выполняли работы, совместно разобрались, в чем дело, и внесли исправления. Но определенный простой в работе критически важных production-сервисов мы получили. Вместе с этим получили и опыт, из которого извлекли следующие выводы: Обязательно составляйте план работ перед их выполнением (было сделано); Тщательно расписывайте в плане работ все операции, которые требуется выполнить для корректной перенастройки системы (в нашем случае в плане работ был пункт об изменении настроек для приложения монолита, но не были достаточно подробно расписаны операции); Выполняйте перекрестные проверки (review) плана изменения настроек системы. В том числе с привлечением представителей отдела разработки, если изменение настроек касается продуктовых приложений; Стройте архитектуру так, чтобы уменьшить количество конфигурационных файлов, в которые нужно внести изменения при смене реквизитов какого-либо компонента системы. Это может быть достигнуто, например, с использованием общего хранилища конфигураций, которые вызываются при деплое приложения (например, Hashicorp Consul или Vault); Все критичные изменения производите во время наименьшей нагрузки (в нашем случае это была ночь) с оповещением о работах всех потенциально задействованных лиц. Даже если что-то пойдет не по плану, в часы наименьшей нагрузки можно выделить больше времени на анализ и грамотное решение проблемы. В общем, придерживайтесь плана, но никогда не теряйте гибкости и не забывайте про инструменты тестирования и мониторинга. Если что-то пойдет не так, они помогут оперативно выявить ошибку и внести в расписание работ все необходимые изменения. Обычно переезд сравнивают с головной болью и пожаром. Но мы подходили к нему постепенно и осознанно — и успешно запустились на новом оборудовании. А еще в процессе работ посмотрели на собственную архитектуру свежим взглядом и внесли необходимые корректировки и оптимизации. Вот основные компоненты нашей новой аппаратной платформы: Серверные шасси: 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 хранилища. Благодаря детальному планированию нам удалось оптимизировать множество конфигураций и политик. В том числе тех, до которых давно не доходили руки. В ходе работ мы добавили дополнительные правила мониторинга. В процессе переезда сформировали новые задачи по развитию нашей инфраструктуры. Впрочем, все самое интересное — впереди: после переезда у нас много амбициозных планов. И мы всегда рады новым коллегам и единомышленникам на этом пути :)