Сегодня мы хотим поделиться тем, как перевозили собственный проект из одного дата-центра в другой. Здесь вы не найдете полезных решений, как повторить подобный переезд оптимальным образом. Это пост боли о том, как миграция выглядит в реальном мире, где часть проблем ты можешь выявить на этапе тестирования, а другую в любом случае получаешь уже на продакшене, просто потому что практически невозможно синтетикой нагрузить железо именно так.

Хостера не называем сознательно - где мог, он шел навстречу. Да и в целом суть поста не в недостатках конкретной компании, а в том, какие проблемы надо предвидеть, планируя модификацию инфраструктуры.

Немного вводных

Помимо участия в командах заказчиков, Максилект разрабатывает собственный продукт - Mondiad advertising platform - рекламную биржу с интерфейсом для конечного клиента, позволяющим создавать и размещать рекламные кампании. Мы уже не раз писали об этом проекте (Clickhouse — непростая жизнь в продакшене, Kafka Streams — непростая жизнь в production, Сервер Ad Exchange — не как у других). 

Проект развивается уже несколько лет. У нас десятки серверов, которые принимают сотни тысяч запросов в секунду (причем, это запросы с низкой latency). Нагрузка на сервера весьма специфическая - мы не раздаем статический контент, а обрабатываем приходящие запросы, так что процессоры, память и диски загружены по полной. Все это происходит автоматически без участия людей.

Особенность бизнес-модели такова, что остановка работы всегда связана даже не с упущенной выгодой, а с фактически потерянными деньгами. Сами посудите, одно дело просто минут 10 не показывать рекламные ролики (это упущенная выгода), но совсем другое - не обрабатывать реальные пользовательские клики. Здесь уже идут прямые потери.

Продукт работает на европейский и американский рынки. Сервера, соответственно, размещены в Майами и в Амстердаме и делят нагрузку примерно пополам. Нюанс в том, что ключевые системы у нас в США, т.е. если отключается американский дата-центр, мы теряем не половину выручки, а 100%, поскольку система просто не работает. Сегодня речь пойдет о миграции как раз этой самой “критичной” части серверов - мы переносили их из Майами в Детройт.

Зачем переезжать

На площадке в Майами наш хостер арендовал стойки у владельца дата-центра, куда ставил собственные сервера. 

Изначально мы ориентировались именно на аренду серверов. Это и дешевле, и меньше накладных расходов ресурсов на виртуализацию (понятно, что они минимальные, но нам важна каждая миллисекунда). На старте мы начинали с одной стойки, и это было выгодно. По мере развития системы мы брали дополнительные сервера, дойдя в итоге до двух полноценных стоек. Отдельно у нас было арендовано два коммутатора, которые позволили реализовать свой выделенный канал интернета - мы полностью управляли этой подсетью.

Недавно хостер построил собственный дата-центр в Детройте и предложил нам переехать. Очевидно, что для него обслуживать сервера на собственной площадке дешевле. Нас же Детройт привлек тем, что в новом дата-центре установили более свежее железо. До этого мы жили на Intel Socket 2011 v1-v3, а здесь - AMD Ryzen 5950x (дата запуска производства процессоров - 11/5/2020). При этом более мощные сервера нам предложили примерно за те же деньги, что мы платили на старой площадке. 

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

Решение о переезде было принято в начале 2023 года. Мы планировали не поднять копию серверов на новом месте, а по сути полностью перестроить все, закончив до 1 сентября. Казалось бы, что могло пойти не так?

Переезд в три этапа

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

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

Синтетические тесты и проблема с NVME-дисками

Надо отметить, что на стадии получения машин все было хорошо - аптайм BMC (Baseboard management controller) у всего, что выделял хостер, был около года. Но на каждой новой машине мы прогоняли свои тесты - оценивали производительность процессора, памяти и дисков, пытаясь сэмулировать нагрузку продакшена.

Первые проблемы вылезли как раз на этом этапе. Производительность NVMe-дисков была сильно ниже ожидаемой и от теста к тесту, от машины к машине она плавала. Этого быть не должно, т.к. конфиги машин были абсолютно одинаковые.

Работать с хостером над решением каких-то проблем по железу - это как взаимодействовать с обычной техподдержкой для физлиц. Стандартный ответ на любой вопрос: “Ничего не знаем, на нашей стороне все работает”. По этому и каждому следующему из эпизодов нам приходилось долго доказывать, что проблема действительно с их оборудованием или настройками, выдавать доступ в свои системы, чтобы они видели метрики. Когда они все-таки убеждались в том, что “мяч на их стороне поля”, на довольно длительное время отправлялись думать и искать решение. 

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

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

Переключение основного трафика

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

Сначала подали 33% продакшн трафика на треть серверов и в этот момент, несмотря на предварительные тесты производительности, заметили, что у части машин проседает QPS (существенно отличается от других машин в кластере). После изучения метрик с этих машин выяснили, что причиной является throttling процессоров - когда они подходят к критической температуре, сбрасывают частоту. Наблюдалось это только на одном из наших сервисов - у него специфическая нагрузка одновременно на процессор, память и сетевые карты, которую не могли сэмулировать синтетические тесты.

Проблему решили довольно быстро. Сначала в ответ на наши жалобы хостер менял термопасту. После нескольких замен снова начал совершенствовать принудительное охлаждение - заказал у вендора кулеры повышенной производительности (22000 RPM) и заменил ими штатные (12000 RPM).

Спустя некоторое время мы добавили в новый дата-центр еще 33% продакшн трафика, еще подождали, а на последней итерации перебросили остальное. Тут-то мы и отхватили целый набор проблем, которые до этого никак себя не проявляли (все по той же причине - синтетикой просто нельзя было сконструировать такую же ситуацию).

Не считая мелких сложностей, мы уперлись в три масштабные проблемы.

И снова перегрев…

Несмотря на принятые ранее меры, на части машин с ClickHouse после подключения 100% трафика снова проявились проблемы с перегревом. На продакшене опять начали перегреваться жесткие диски, посылая кучу алертов - температура доходила до 50 С, при ней диски быстро деградируют. Уже по накатанной хостер заказал мощные кулеры и через пару недель заменил ими штатные.

Почему все это не проявилось раньше? Видимо, сказывалось расположение в определенной стойке или место в самой стойке. Известно же, что самые “холодные” места внизу. Разница небольшая - 1-3С - но нам хватало.

Самопроизвольный ребут

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

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

За все время проблемы проявились только на 12% серверов. Но остановка отдельных серверов в нашем случае приводит к тому, что мы пропускаем запросы от внешних систем и теряем деньги. Чем больше таких скипов - тем хуже.

Поскольку сделать с самопроизвольным ребутом на своей стороне мы ничего не могли, такие машины сдавали хостеру. Он выдавал новые в аналогичном конфиге. 

Проблемы с сетью

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

Дело в том, что у нашего продукта есть огромное количество метрик, настроенных дашбордов и т.п., но по понятным причинам наблюдать вообще за всеми невозможно (ресурсы наши не безграничны). В штатном режиме мы следим за основными системными и бизнес-показателями. И если они выходят за рамки “нормального” диапазона, начинаем копать глубже. Например, у нас есть важная бизнес-метрика по скипам - оборванным соединениям с внешними системами. Пока теряются единичные коннекты, мы считаем, что ситуация штатная. Как только скипов становится сильно больше, идем смотреть логи. К сожалению, такой подход означает задержку при выявлении некоторых проблем. Но позволяет нам немного оптимизировать обслуживание.

Как выяснилось на разборе выросшего количества скипов, коммутатор в одном из “наших” шкафов оказался глючным - на мелких пакетах были потери 2-3%. Возможно, для другой нагрузки это не критично, а для нас выливается в серьезные потери. 

Коммутатор заменили (опять же, на стороне хостера) - проблема решилась.

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

Переезд сборки и деплоя

Ближе к концу переезда мы стали переводить в Детройт процессы сборки релизов и их автоматического тестирования на работоспособность базового функционала. Столкнулись с тем, что у нас начали падать некоторые автотесты. Эту проблему решили, используя локальную машину на AMD Ryzen. Так совпало, что компьютер одного из разработчиков имел такой же процессор, как и новые сервера. Поэтому он мог легко воспроизводить все проблемы с автотестами у себя и относительно быстро их чинить.

Экстренное ускорение

Дата, когда наши сервера в Майами будут отключены, обсуждалась с самого начала. Но тут произошло классическое расхождение в понимании сроков. Мы сказали, что “планируем переехать к такому-то числу”, а хостер услышал, что “мы точно закончим к этому числу”, и согласовал с владельцем дата-центра на эти даты перестройку инфраструктуры. На самом деле это была одна из ошибок переезда - нужно было с самого начала прояснить момент со сроками. И позже нам это аукнулось.

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

Нам оставалось только ускориться. Мы готовили “план Б” - предварительно с хостером согласовали перенос сроков отключения на пару дней. Но по факту к 1 сентября все-таки успели.

Жизнь после переезда

Хотя по части проблем мы уже нашли решения, на момент переезда все это работало не очень стабильно на больших нагрузках - наблюдались некоторые скипы трафика. И мы просто “завалили проблему серверами”. Это тоже было не самое быстрое решение - заказ серверов требует времени, перед вводом в эксплуатацию их в любом случае надо протестировать. Но когда мы подключили дополнительное железо, уровень скипов упал до приемлемого - мы могли так работать в течение какого-то времени.

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

Последний месяц мы занимались post-migration tasks, т.е. доделывали мелочевку и решали небольшие мелкие проблемы, которые вылезли уже после миграции: где-то не успели настроить резервное копирование, где-то добавляли и убирали метрики, где-то адаптировались под новое железо. У того же Aerospike есть свои особенности при работе с NVMe - на каждом диске желательно иметь 4+ раздела, иначе весь обмен с дисков идет через одну линию PCI-Express. До этого мы держали его данные только на SATA-SSD и там с этой проблемой не сталкивались из-за другой архитектуры.

Итоги и выводы

Как и собирались, мы построили более отказоустойчивую инфраструктуру. Обеспечили себе запас по производительности в два раза (раньше этот запас был не более 15%), дублировали питание, перестроили сеть - оптимальнее развели балансировщики и в целом реализовали более устойчивую схему. В Майами все это было недоступно.

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

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

Спасибо за помощь при подготовке статьи Игорю Иванову, Николаю Еремину, Александру Метелкину, Денису Палагута и Андрею Бурову.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.