От всей команды К2 Cloud
Эта статья про железо и автоматизацию нашей инфраструктуры в ЦОДах писалась задолго до событий, с которыми несколько дней назад столкнулись коллеги из Яндекса. Мы сопереживаем коллегам и всем, кого затронула эта ситуация, и желаем скорее вернуться к привычному ритму работы. Наша команда готова помочь с резервированием вашей инфраструктуры в приоритетном порядке: Яндекс договорился с несколькими провайдерами об ускоренном размещении ресурсов. K2 Cloud – в их числе.
Оставьте заявку с кодовым словом CloudBro, мы обработаем ее в первую очередь.
Привет, Хабр! Меня зовут Антон Бушный, я тимлид инфраструктурных инженеров в K2 Cloud. В этой статье мы поговорим про железо — о нем, как нам кажется, говорят непростительно мало. А ведь любое приложение, сервис, Kubernetes-кластер не существует в вакууме — он обязательно работает на физической инфраструктуре. Речь пойдет о концепции построения большой инфраструктуры, но конкретные модели серверов и замеры производительности сравнивать не будем, разговор верхнеуровневый.
Статья будет состоять из двух блоков. Первый — про физику и то, как с ней взаимодействуют инженеры. Второй посвящен автоматизации и тому, как она помогает в работе с инфраструктурой. За прошедшие годы мы выработали много полезных практик в обеих областях и хотим ими поделиться.
Кто мы такие и почему нам есть что рассказать
K2 Cloud — облачный провайдер, который входит в топ-10 крупнейших облачных платформ России. Облачная платформа у нас собственной разработки, основная часть кода написана на Python, а еще мы, конечно, используем open-source-решения — например, OVN для виртуальных сетей.
Сейчас мы присутствуем в четырех ЦОДах в Москве и одном в Санкт-Петербурге. Помимо основной инсталляции, у нас на поддержке несколько частных инсталляций — копий нашей платформы, развернутых у заказчиков.
Ключевая особенность нашей инфраструктуры в динамичности — нам регулярно нужно подстраиваться под потребности многочисленных клиентов, поэтому оборудование постоянно вводится, выводится, перемещается между ЦОДами и порой меняет владельцев. Делать это приходится быстро — сроки, как обычно, горят, а иногда срываются по самым фантастическим причинам.
Например, однажды наши инженеры приехали на монтаж большой партии серверов в один из ЦОДов и обнаружили, что единственная дорога к нему перекрыта ж/д составом.
Сами они смогли перелезть через вагоны, но машина с оборудованием — увы. В итоге монтаж отложился более чем на полтора дня — ждали, пока состав уедет :)
Как все начиналось: стойки, которые лучше не видеть
Вернемся на рубеж 2018–2019 годов. Наше облако было тогда далеко не такого масштаба, как сейчас. Инфраструктуру строила группа эксплуатации, у каждого была своя специализация, зона ответственности и каждый управлял оборудованием так, как считал правильным, а друг с другом инженеры координировались слабо. В результате получалась какая-то итоговая инфраструктура.
Когда в облаке появлялась новая стойка и в ней работал только один инженер, все выглядело вполне цивильно и презентабельно, как здесь на фото:
Через месяц-два, когда в стойке размещалось уже несколько сервисов, начинало происходить что-то вот такое:
Видно, что еще можно что-то разобрать, но хаос уже формируется. А спустя полгода и больше каждая наша стойка неизбежно превращалась вот в это:
Причина, думаю, понятна — слабое планирование, а зачастую и полное его отсутствие. Но была и вторая — громоздкая сеть.
У нас работали две разные сети: Ethernet и InfiniBand, которые стыковались коммутаторами на уровне ядра. В каждой стойке стояли коммутаторы обеих сетей. По высокоскоростной InfiniBand шел трафик storage и виртуальных сетей, а также миграция виртуальных машин; а по Ethernet осуществлялось взаимодействие сервисов облака друг с другом и управление.
На бумаге сеть была спроектирована надежной — в каждой группе из двух стоек находилось по паре Ethernet и InfiniBand свичей, для обеспечения отказоустойчивости при обрыве любого линка и отказа любого из коммутаторов. Однако на практике, поскольку коммутаторы стояли в верхней части стоек спереди — линки скапливались вокруг свичей, и также очень много линков выходило из стойки и приходило в другую и наоборот.
В итоге из стойки выходило огромное количество проводов, которые скапливались на крыше, как видно на правом фото; а спереди стойка выглядела так, будто ее стошнило или что-то в этом роде. Страшно и некрасиво — да, но какие реальные минусы? Они, конечно, были:
Частые сбои при работах в ЦОДе. Инженер работает с одним сервером, а у другого, стоящего выше или ниже, отключаются линки: кто-то что-то задел или перепутал.
Несбалансированное заполнение стоек. Низ забит серверами под завязку, а вверху копится коммутация и остается пустоеместо — свитчи потребляют сильно меньше.
Неравномерная нагрузка по электропитанию — низ загружен больше верха.
Негатив инженеров. Инженерам в ЦОДе было попросту неприятно копаться во всем этом. У администраторов причины другие: например, в команду, которая занимается платформенными сервисами, устраивался новый инженер, рассчитывая крутить сервисы на Kubernetes и больше ничего не делать. А поскольку инфраструктурой у нас занимались все, ему говорили: «Выходит новый сервис, подбери под него серверы и не забудь поставить правильные диски». Заниматься этим нравилось не всем. Оговорюсь: далеко не у всех была такая реакция, но прецеденты случались.
Все это как-то работало, и нам долго казалось, что это неизбежно — такова специфика работы. Оставалось жить с этим и минимизировать последствия.
На рубеже 2019–2020 годов, незадолго до начала ковида, у нас в К2 начался «период турбулентности». На нас обрушилась череда критических неудач с очень печальными последствиями.
Во-первых, возникла ситуация, когда несколько стоек полностью отключились из-за того, что их перегрузили по питанию. причем каскадом, а в одной даже оплавился вводной разъём pdu вызвав задымление.
Во-вторых, параллельно начались проблемы в сети и в storage. Наша сеть на InfiniBand, по сути, устарела — при обновлении версии ОС возникали проблемы с драйверами, постоянно останавливалась очередь IB-пакетов, и вывести хост из этого состояния можно было только полной перезагрузкой. Хосты приходилось перезагружать постоянно. Обновить саму сеть можно было лишь одновременным полным отключением и обновлением всего, чего мы не могли себе позволить.
Наконец, storage. СХД были «отказоустойчивыми» только в кавычках: отказывала одна половина, а вторая, которая должна была принять нагрузку, падала вместе с ней и доступ к данным пропадал.
Время перемен
В связи со всеми вышеописанными событиями очень скоро стало понятно, что облако работает на пределе, нужно все менять, и довольно быстро.
Шаг первый — единое окно по железу. Мы поняли, что менять нужно все, и быстро: облако работало на пределе возможностей, да и мы сами тоже.
Начали с взаимодействия команд с инфраструктурой. Стало ясно, что нужны люди, которые станут единым окном по всем вопросам, связанным с железом, для остальных команд.
В их зону ответственности вошли текущие решения и задачи, которые раньше были размазаны между командами — например, мониторинг железа и тестирование нового оборудования. Новая схема взаимодействия команд выглядит вот так:
Теперь инженеры других специализаций решают вопросы с инфраструктурой через отдельную команду инфраструктуры. Вначале это было буквально пара человек, сейчас — большая команда. Новые инженеры по инфраструктуре сформулировали, к чему мы хотим прийти.
Новые принципы
Появились очень четкие цели для инфраструктурной команды:
● унифицировать подключение серверов и стоек — все должны подключаться одинаково;
● минимизировать число линков, выходящих из стойки, и развернуть коммутаторы портами назад, чтобы линки не копились;
● распределять оборудование по стойке с учетом энергопотребления, чтобы стойки больше не падали;
● минимизировать пустое пространство. Вопрос чисто экономический: чем больше пустых юнитов, тем больше стоек нужно арендовать, а это невыгодно.
Смежные команды выработали свои планы, которые нам тоже предстояло учитывать:
● сетевики решили вынести коммутаторы уровня ядра в отдельные сетевые стойки и, главное, полностью отказаться от InfiniBand и строить сеть только на Ethernet, оборудование теперь обновляется на обычное Ethernet, а архитектура сети меняется;
● команда Storage отказалась от неэффективных СХД в пользу распределенных систем хранения: любые данные лежат на разном физическом железе в двух или трех экземплярах, в зависимости от типа хранения. Падение одной железки больше не приводит к потере доступа к данным.
Из всего этого родились новые стандарты. Переезд на них занял долгие два с половиной года, и мы пользуемся ими до сих пор с небольшими доработками. В чем суть — пробежимся вкратце.
Классификация стоек
Облачные стойки — самый распространенный тип, в них работает облако. Они собираются по единому стандарту и похожи друг на друга как две капли воды без исключений.
Сетевые стойки — в них находится ядро сети и производятся все внешние подключения к облаку. Это, в первую очередь, интернет, а еще наша услуга подключения внешнего оборудования заказчика, стоящего в ЦОДе, или его выделенного канала связи. Все физические подключения проводятся в сетевые стойки. Количество этих стоек в одном цоде должно быть кратно двум, тк оборудование в них полностью задублировано.
Но была небольшая проблема: в частных инсталляциях количество стоек ограничено — из-за малого размера инсталляции или невозможности купить новые стойки. Тогда для небольших инсталляций мы сделали комбинированные стойки: по ней проходит невидимая граница, и нижняя часть собирается по стандарту CloudRack, а в верхней — сетевое оборудование. Это компромисс между экономичностью и стандартом.
Как я уже сказал, все облачные стойки должны были собираться по единому стандарту. И вот этот единый стандарт выглядит на схеме в кратком виде, как на картинке слева.
Стандарт преследует три цели:
Минимум пустого пространства. Все юниты стойки заняты, коммутаторы стоят в центре.
Масштабирование облака. Компоненты подобраны так, чтобы в зависимости от массовости роли в облаке их на стойку приходилось больше или меньше. Даже из одной стойки, собранной по стандарту, можно собрать небольшую инсталляцию со всем необходимым для запуска платформы.
Корректное расключение по питанию. Стандарт определяет, в какой блок PDU (Power Distribution Unit, устройства распределения питания) подключается каждое устройство.
Стандарт вырабатывали на основе расчетов: мы реально замеряли энергопотребление каждого сервера, сколько в среднем и в пике потребляет гипервизор, узел со storage и так далее. Кроме того, закупили PDU с функцией мониторинга — они в реальном времени следят за нагрузкой. Данные выведены в общую облачную систему мониторинга Zabbix и в DCIM-систему для инженеров ЦОДа. Перед работами в облаке инженер ЦОДа может открыть данные по энергопотреблению и убедиться, что превышения нет.
Параллельно сетевые инженеры переделали сеть и пришли к классической схеме leaf-spine. Выглядит она вот так:
В каждой стойке устанавливаются два leaf-коммутатора и один mgmt leaf. Они подключаются к spine-коммутаторам в сетевых стойках, а с внешним миром облако стыкуется через еще одну пару коммутаторов — border leaf.
Три коммутатора ставятся в центре новой стойки: два leaf, по которым ходит весь продуктивный трафик, и один mgmt коммутатор для управления серверами. Почему mgmt. коммутатор один? Его отказ не приводит к сиюминутным последствиям: мы теряем мониторинг и управление серверами, но заказчиков это сразу не затрагивает.
Про leaf стоит сказать отдельно. Долгое время мы использовали коммутаторы Mellanox. Их ключевая особенность — необычный форм-фактор в пол-юнита: в специальное шасси в одном юните ставятся два полностью независимых коммутатора. Поэтому мы называли их «leaf левый» и «leaf правый». Позже закупать эти коммутаторы стало невозможно, и появились другие — полноразмерные, которые мы ставим просто один над другим.
После изменения стандарта из стойки выходит всего шесть линков: два медных для менеджмента и четыре оптических 100G — по два в каждый спайн. Оптику мы дополнительно защищаем специальной «броней» из кабельного органайзера (ее краешек виден на правом фото), чтобы минимизировать воздействие на линки, например, при прокладке новой коммутации.
Крыши стоек очистились, горы проводов исчезли — вроде все выглядит гораздо презентабельнее.
Отдельно отмечу: коммутаторы мы начали устанавливать портами назад, а при такой установке нужно учитывать направление выдува.
В большинстве коммутаторов холодный воздух входит со стороны портов и выходит с обратной стороны. В нашем случае все наоборот: воздух должен входить с обратной стороны свитча и выдуваться со стороны портов. У большинства коммутаторов это дополнительная опция, которая указывается при заказе.
Самостоятельно разворачивать вентиляторы вендоры не рекомендуют. У нас проблем не возникло, но повторять не советуем — только в случае крайней необходимости. Все новые коммутаторы, которые мы закупали, а не переносили из старой инфраструктуры, мы уже брали с правильным направлением выдува.
Теперь коммутация всех серверов выглядит абсолютно одинаково: к каждому серверу подходит ровно четыре линка. По два в два leaf-коммутатора — по ним идет весь продуктивный трафик, в том числе основная кластерная сеть, связывающая все серверы в пределах одной зоны доступности. Если роли сервера нужна дополнительная сеть, она подается по этим же линкам в виде VLAN. Число физических линков не меняется, а число сетей зависит от роли сервера. Еще один медный линк для менеджмента — для BMC-контроллера сервера, и один медный линк, который мы назвали Cluster Backup.
Про последний расскажу подробнее. Мы долго думали, стоит ли его делать, т.к. мы защитились от отказа leaf-коммутатора, поставив два, и от отказа линков, потому что линков тоже два. Но не защитились от отказа единственной сетевой карты, в которую подключены оба линка: ее могут неправильно прошить, она может сгореть и доступ к серверу пропадает. Cluster Backup решает эту проблему: администратор может хотя бы зайти на сервер по SSH и что-то сделать. Сеть сделали не зря: несколько раз она нас реально выручала.
Стандарт унифицировал и порты, т.к. теперь за каждым юнитом закреплен свой порт: два порта на management-коммутаторе (кластер-бэкап и менеджмент) и парные порты на двух leaf для кластерной сети. Длинные планы коммутации больше не нужны: в заявке пишется одна фраза — скоммутируйте сервер по стандарту. Просто и удобно.
Теперь немного о том, как сетевые подключения описываются в манифестах. У нас в качестве системы конфигурации используется Puppet (некоторым он возможно знаком под именем OpenVox – новый fork с почти идентичным функционалом), и, вот фрагмент конфига сервера при его добавлении в inventory (hiera). Слева показан фрагмент его конфига, где описывается подключение сервера: видны все интерфейсы, о которых я рассказал — cluster bond из двух линков, clusterbackup, mgmt. Дополнительная сеть Storage — это VLAN поверх кластерной сети.
Порты на коммутаторах тоже настраиваются автоматически. На упомянутых Мellanox используется ОС Cumulus Linux, поэтому там можно запустить Puppet-агента и настраивать их так же, как обычный Linux-сервер. Если на коммутаторе агента не запустить, используем Ansible.
Главное, что никакие порты на коммутаторах не настраиваются руками — все идет через манифесты. Так обеспечивается единый подход к инфраструктуре.
Вот как выглядит готовая коммутация в обычных и сетевых стойках. Фото «непричесанные», я специально снял их как есть, в моменте.
Автоматизация: путь голого сервера до гипервизора
Наконец-то переходим ко второй части! Проще всего рассмотреть все, что мы разработали, на примере типовой задачи — ввода нового сервера в облако.
Представьте: приехала голая железка, которую нужно довести до состояния готового гипервизора для запуска виртуальных машин в составе облака. Процесс разбиваем на блоки:
определить место установки;
подготовить конфиги для систем;
подготовить сам сервер;
разлить операционную систему;
ввести сервер в облако;
проверить, что все выполнено корректно: инфраструктура все-таки продуктивная.
Шаг 1. Определяем место установки
Нужно выбрать по стандарту с учетом роли будущего сервера.
Чтобы понимать, что и где стоит в ЦОДах, нужна система инвентаризации — DCIM (Data Center Infrastructure Management). Исторически так сложилось что для этих целей мы используем OpenDCIM.
Не настаиваем, что нужна именно такая система — она довольно старая, и сейчас есть решения получше. Но основное что от этой системы требуется, помимо веб-интерфейса - JSON-подобный API, через который можно и получать информацию и добавлять ее.
Начали мы с разработки консольного клиента для этой системы на python3. Благодаря ему администратор прямо не выходя из терминала, узнает, где стоит сервер, с которым нужно провести работы, смотрит его характеристики и состав всей стойки.
Эти данные объединяются с информацией из облака — хостнеймами и ролями, — и складывается полная картина. Она сохраняется, даже если сервер выключен или не отвечает: информация хранится в DCIM отдельно.
Искать свободное место, просматривая клиентом все стойки? Можно, но лучше сделать утилиту, которая выводит сводную информацию с учетом стандарта где есть место под сервер конкретной роли. Проверка идет по DCIM-системе и манифестам, о которых говорилось выше.
Т.е, если порты не заняты, место, скорее всего, свободно; если в DCIM пусто — точно свободно. Утилита обрабатывает эти данные и выводит итог: в каких стойках и в какие юниты можно ставить сервер. В результате раньше поиск места занимал до получаса, теперь — секунды и одна команда.
Информация попадает в систему, конечно, не вручную. В некоторых автоматизация есть из коробки, но наша ее не имела, поэтому мы написали модуль для Puppet из двух скриптов: один собирает информацию и сохраняет ее локально на сервере, второй загружает в DCIM.
Инженерам ЦОДа остается только физически указать местоположение сервера. Автоматизация сама оповещает их, когда в облаке появилось новое оборудование.
Шаг 2. Готовим конфиги
Конфиги чаще всего нужно подготовить для трех систем: внутреннего DNS и уже упомянутых Puppet и Ansible. Вариантов реализации было огромное количество, но мы пришли к ситуации, как на картинке.
Изначально мы планировали сложную автоматизацию на CI/CD, на основе API и так далее. В итоге мы пришли к банальному решению — локальным скриптам.
Это скрипты, которые инженеры запускают локально на своих машинах: они вносят изменения в репозитории в соответствии со стандартом, а затем инженер сам пушит изменения от своего имени. Время работы это, понятно, сильно не сократило, зато человеческий фактор стремится к нулю: автоматизация вносит изменения, человек перепроверяет, а второй человек перепроверяет еще раз на review. Вероятность того, что описка или ошибка пройдет, практически нулевая.
Остался доволен и наш отдел информационной безопасности — ведь речь о продуктивной инфраструктуре. Автоматизация, которая могла бы незаметно наломать дров, в процесс не вмешивается — изменения пушатся от лица конкретного человека, и конкретный человек проводит review.
Шаг 3. Готовим сервер
Подготовка сервера включает:
● приведение прошивок (BIOS и других) к единому виду. Зачем? По разным причинам: например для предотвращения потенциальных проблем при миграции ВМ между гипервизоре;
● настройку параметров BIOS и BMC от банальной установки пароля до отключения режима энергосбережения, который иногда включают вендоры. В облаке он не нужен — все серверы должны работать на максимальной производительности;
● настройку storage, например сборку RAID 1 под операционную систему;
● PXE boot.
У большинства серверов все это можно сделать вручную через веб-интерфейс BMC-контроллера. Для примера — интерфейс IDRAC от Dell, пожалуй, самый красивый среди популярных вендоров:
Казалось бы, эти интерфейсы — они все разные, ВМС у всех разные, как это все унифицировать, если вендоров много в инфраструктуре? Но оказалось, что универсальный механизм взаимодействия с ВМС существует, и называется он RedFish API.
Для большинства серверов и вендоров все подходит в полной мере или с нюансами (мы отметили, есть ли тот или иной функционал). Не подходят серверы, где поддержка не заявлена или заявлена, но при использовании возникли серьезные проблемы. Например, у одного из вендоров контроллер просто зависал от приходящих запросов и ничего не отвечал.
Пример работы с Redfish API: здесь два запроса, с помощью которых можно выполнить однократный PXE-boot в популярном OpenBMC, — PATCH и POST.
Первым мы задаем однократную boot-опцию PXE, вторым отправляем сервер в мягкую перезагрузку, после чего он загружается по PXE. Для разных BMC запросы немного различаются, но их удобно писать с помощью ИИ: решение либо открытое, как OpenBMC, либо очень распространенное благодаря популярности вендора, как у Dell и HP. Информации в интернете много, поэтому нейросети спокойно генерируют такие запросы, и чаще всего они правильные.
На основе всего этого мы разработали утилиту, которая выполняет все перечисленное и сокращает время подготовки.
Мы сделали ее мультивендорной, для каждого вендора прописали отдельный класс. При запуске она определяет вендора сервера, загружает нужный класс и дальше начинают работать методы работы с Redfish.
Это принесло свои плоды. Раньше прокликивание с ожиданием всех загрузок и перезагрузок занимало до часа на сервер, теперь — 15 минут. И это время не растет с количеством серверов: шесть серверов тоже готовятся 15 минут, потому что мы запускаем шесть экземпляров утилиты параллельно, а администратор просто проверяет, что все хорошо.
Грабли Redfish — дикая асинхронность! Вы совершенно не понимаете, сколько будет выполняться та или иная задача. Например, обновление BIOS зависит от огромного количества факторов от модели сервера до фаз звезд и Луны, поэтому приходится обвязываться полукостылями. Поэтому всегда нужно добавлять какие-то таймеры, которые периодически будут посылать запросы, проверяя, ВМС уже готов, к примеру, применять следующую задачу или нет. И даже если ВМС готов, лучше еще немного подождать. И тогда уже следующая задача точно пройдет.
Шаг 4. Разливаем операционную систему
Здесь нужна автоматическая система разливки. Для RHEL-подобных систем традиционно используют Cobbler — одно из самых распространенных решений, работающее в паре с DHCP-сервером (у нас это dnsmasq).
Мы написали еще два модуля для нашего любимого Puppet, они берут информацию из Hiera, парсят ее и превращают в конфигурационные файлы для этих систем.
В классическом PXE на открытии окна установки ОС все бы закончилось: параметры установки пришлось бы прокликивать вручную.
Но в Anaconda есть механизм автоматической установки — kickstart-файлы. Cobbler делает kickstart-файл доступным установщику по HTTP (порт 80) и подставляет в параметры загрузки ссылку, откуда его брать. И таким образом установка идет автоматически, ничего прокликивать не нужно.
Вот фрагмент kickstart-файла: в нем задаются часовой пояс, диск для установки, разметка диска, параметры сети, пользователи и многое другое. Все это выполняется установщиком автоматически. На выходе получается не просто сервер с ОС, а сервер, готовый к дальнейшему деплою сервисов: диск размечен правильно, установлены дополнительные пакеты, например Puppet-агент, настроены сеть и SSH ключи. Сразу после разливки ОС мы заходим на сервер по SSH и продолжаем работу.
Шаг 5. Вводим сервер в облако
Регистрацией сервера в облаке занимается утилита bootstrap, вхрдящая в состав нашей платформы. Похожие есть во многих облаках, например в OpenStack. Резонный вопрос: почему не использовать для этого наш любимый Puppet? Около 80% конфигурации сервера делается с его помощью. Но Puppet не умеет кое-чего из необходимого. Он не может выполнять радикальные действия вроде перезагрузки сервера и не может запускать сам себя на других хостах, например, чтобы подготовить и задеплоить конфигурационные файлы. Bootstrap умеет все это: например, может отправить хосту команду на перезагрузку для применения настроек, дождаться, пока он снова станет доступен, и продолжить работу.
Шаг 6. Проверяем
Последний шаг — проверка. Для нее мы написали еще одну утилиту на Python — c2check. Она прогоняет фиксированный набор тестов, зависящих от роли сервера и версии ОС, сравнивает полученные результаты с эталонными и печатает итог в виде таблицы со статусами ok / not ok.
На работу проверяемого сервера утилита не влияет: все проверки заранее протестированы и безопасны, никакого дестроя не спровоцирует. Администратор сразу видит, есть ли проблемы, и при необходимости их исправляет.
Итак, мы прошлись по всем пунктам, и каждый покрыт автоматизацией. Сейчас все это достаточно разрозненно, и в планах — объединить все это в единый суперсервис с одной кнопкой: «ввести сервер», «вывести сервер», «закрыть ворота» и так далее. Предела совершенствования автоматизации не существует.
Выводы
Какие выводы можно сделать из всей этой истории, которую я рассказал? На самом деле, достаточно банальные, но тем не менее их стоит проговорить и не стоит о них забывать.
Стандартизация инфраструктуры — это инвестиция в будущее. У нас наши вложения в разработку стандарта и автоматизации окупились уже многократно. Было уже несколько крупных проектов после того, как мы их сделали, например, мы запускали регион нашего облака в Санкт-Петербурге, мы запускали новую частную инсталляцию, осуществляли расширение одной из наших зон доступности в Москве в другой ЦОД. Во всех этих случаях нас очень выручал наш стандарт и автоматизация, проблем уже не возникало.
Грамотно спроектировать инфраструктуру с самого начала дешевле, чем переделать ее под нагрузкой, как это делали мы несколько лет назад, когда ситуация уже стала реально критической и являлась практически вопросом выживания. Поэтому не повторяйте наших ошибок - стройте инфраструктуру по возможности сразу правильно.
Надеемся, информация была вам полезна и вы что-то из нее примените в своей инфраструктуре. А если вашей инфраструктуры вам вдруг перестало хватать, добро пожаловать к нам!