Сегодня мы хотим поделиться тем, как перевозили собственный проект из одного дата-центра в другой. Здесь вы не найдете полезных решений, как повторить подобный переезд оптимальным образом. Это пост боли о том, как миграция выглядит в реальном мире, где часть проблем ты можешь выявить на этапе тестирования, а другую в любом случае получаешь уже на продакшене, просто потому что практически невозможно синтетикой нагрузить железо именно так.
Хостера не называем сознательно — где мог, он шел навстречу. Да и в целом суть поста не в недостатках конкретной компании, а в том, какие проблемы надо предвидеть, планируя модификацию инфраструктуры.
Немного вводных
Помимо участия в командах заказчиков, Максилект разрабатывает собственный продукт — 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%), дублировали питание, перестроили сеть — оптимальнее развели балансировщики и в целом реализовали более устойчивую схему. В Майами все это было недоступно.
Новая инфраструктура обходится нам не дороже, чем старая. Но, конечно, мы на себе прочувствовали, что “переезд хуже пожара”. Мы были готовы к тому, что какие-то проблемы вылезут только на проде. Синтетикой вы не сможете отловить все проблемы, которые могут возникнуть. И поэтому мы придумали схему с постепенным переключением трафика и увеличением мощностей на новой площадке.
Единственная серьезная ошибка, которую мы допустили, — изначально не проработали резервный план на тот случай, если не будем успевать в сроки. Благодаря запасам, заложенным в других местах, мы все-таки успели. Но было жарко!
Спасибо за помощь при подготовке статьи Игорю Иванову, Николаю Еремину, Александру Метелкину, Денису Палагута и Андрею Бурову.