Привет, Хабр! Представляю вашему вниманию перевод статьи «4 инженера, 7000 серверов и одна глобальная пандемия» Адиб Дау.
Если этот заголовок не вызывает у вас легкой мурашки по спине, вам следует перейти к следующему абзацу или посетить нашу страницу, посвященную карьера в компании - мы хотели бы поговорить.
Кто мы
Мы — команда из четырех пингвинов, которые любят писать код и работать с оборудованием.В свободное время мы отвечаем за развертывание, обслуживание и эксплуатацию парка из более чем 7000 физических серверов под управлением Linux, распределенных по 3 различным центрам обработки данных по всей территории США.
У нас также была возможность сделать это за 10 000 км от объектов, не выходя из собственного офиса, который расположен в нескольких минутах езды от пляжа на Средиземном море.
Проблемы масштаба
Хотя для стартапа имеет смысл начать с размещения своей инфраструктуры в облаке из-за относительно небольших первоначальных инвестиций, мы в Outbrain решили использовать собственные серверы.Мы сделали это потому, что затраты на облачную инфраструктуру намного превышают затраты на эксплуатацию собственного оборудования, расположенного в дата-центрах после разработки до определенного уровня.
Кроме того, ваш сервер обеспечивает высочайшую степень контроля и возможностей устранения неполадок.
По мере нашего развития проблемы всегда рядом.
Более того, они обычно приходят группами.
Управление жизненным циклом серверов требует постоянного самосовершенствования, чтобы иметь возможность правильно функционировать в условиях быстрого увеличения количества серверов.
Программные методы управления группами серверов в центрах обработки данных быстро становятся громоздкими.
Обнаружение, устранение неполадок и устранение сбоев при соблюдении стандартов QoS становится вопросом жонглирования чрезвычайно разнообразными массивами оборудования, различными рабочими нагрузками, сроками обновления и другими приятными вещами, о которых никто не хочет беспокоиться.
Управляйте своими доменами
Чтобы решить многие из этих проблем, мы разбили жизненный цикл сервера в Outbrain на его основные компоненты и назвали их доменами.Например, один домен охватывает требования к оборудованию, другой — логистику, связанную с жизненным циклом запасов, а третий — связь с полевым персоналом.
Есть еще один момент, касающийся аппаратной наблюдаемости, но мы не будем описывать все моменты.
Нашей целью было изучить и определить домены, чтобы их можно было абстрагировать с помощью кода.
После разработки рабочей абстракции она передается в ручной процесс, который развертывается, тестируется и уточняется.
Наконец, домен настроен для интеграции с другими доменами через API, образуя целостную, динамичную и постоянно развивающуюся систему жизненного цикла оборудования, которую можно развертывать, тестировать и наблюдать.
Как и все другие наши производственные системы.
Принятие такого подхода позволило нам правильно решить многие проблемы — путем создания инструментов и автоматизации.
Нужен домен
Хотя электронная почта и электронные таблицы на первых порах были жизнеспособным способом удовлетворения спроса, они не стали успешным решением, особенно когда количество серверов и объем входящих запросов достигли определенного уровня.Чтобы лучше организовать и расставить приоритеты входящих запросов в условиях быстрого расширения, нам пришлось использовать систему обработки заявок, которая могла бы предложить:
- Возможность настройки просмотра только нужных полей (просто)
- Открытые API (расширяемые)
- Известный нашей команде (понятный)
- Интеграция с нашими существующими рабочими процессами (унифицированными)
Использование Jira для входящих запросов и управления внутренними задачами позволило нам создать единую канбан-доску, позволяющую смотреть на все процессы в целом.
Наши внутренние «клиенты» видели только запросы на оборудование, не вникая в менее существенные детали дополнительных задач (таких как улучшение инструментов, исправление ошибок).
Канбан-доска в Jira
В качестве бонуса то, что очереди и приоритеты теперь были видны всем, позволило понять, «где в очереди» находился тот или иной запрос и что ему предшествовало.
Это позволило владельцам изменить приоритетность своих запросов без необходимости обращаться к нам.
Перетащите и все.
Это также позволило нам отслеживать и оценивать наши соглашения об уровне обслуживания в соответствии с типами запросов на основе показателей, сгенерированных в Jira.
Область жизненного цикла оборудования
Попробуйте представить себе сложность управления оборудованием, используемым в каждой серверной стойке.Еще хуже то, что многие аппаратные средства (ОЗУ, ПЗУ) можно перемещать со склада в серверную и обратно.
Они также выходят из строя или списываются, заменяются и возвращаются поставщику для замены/ремонта.
Обо всем этом необходимо донести до сотрудников службы колокейшн, занимающихся физическим обслуживанием оборудования.
Чтобы решить эти проблемы, мы создали внутренний инструмент под названием Floppy. Его задача:
- Управление коммуникациями с полевым персоналом, агрегирование всей информации;
- Обновление данных «склада» после каждого выполненного и проверенного ремонта оборудования.
Таким образом, мы используем один и тот же инструмент для визуализации склада и других производственных нужд. 
Пульт управления складским оборудованием в Графане
Для серверных устройств, находящихся на гарантии, мы используем другой инструмент, который называется «Диспетчер».
Он:
- Собирает системные логи;
- Формирует отчеты в формате, требуемом поставщиком;
- Создает запрос от поставщика через API;
- Получает и сохраняет идентификатор приложения для дальнейшего отслеживания его хода.
Вывод консоли Дженкинса
Коммуникационная область
Чтобы идти в ногу с быстрым ростом нашего бизнеса, который требует постоянно растущих мощностей, нам пришлось адаптировать методы работы с техническими специалистами в местных центрах обработки данных.Если сначала масштабирование подразумевало покупку новых серверов, то после проекта консолидации (на базе перехода на Kubernetes) это стало совсем другим.
Наша эволюция от «добавления стоек» к «перепрофилированию серверов».
Использование нового подхода также потребовало новых инструментов, которые позволили более комфортно взаимодействовать с персоналом дата-центра.
Эти инструменты были необходимы для:
- Простота;
- автономия;
- Ээффективность;
- Надежность.
Без нашего вмешательства и без регулярного поднятия всех этих вопросов относительно загруженности, рабочего времени, наличия оборудования и т.д. Для этого мы установили iPad в каждом дата-центре.
После подключения к серверу произойдет следующее:
- Устройство подтверждает, что этот сервер действительно требует доработки;
- Приложения, работающие на сервере, закрываются (при необходимости);
- На канале Slack публикуется набор рабочих инструкций с объяснением необходимых шагов;
- По завершении работы устройство проверяет корректность конечного состояния сервера;
- Перезапускает приложения при необходимости.
Благодаря широкому набору возможностей (мы постоянно расширяли функционал) бот облегчил им работу, а нам жизнь намного проще.
Таким образом мы оптимизировали большую часть процесса перепрофилирования и обслуживания серверов, исключив себя из рабочего процесса.
iPad в одном из наших дата-центров
Аппаратный домен
Надежное масштабирование инфраструктуры нашего центра обработки данных требует хорошей визуализации каждого компонента, например:- Обнаружение аппаратного сбоя
- Состояния сервера (активный, размещенный, зомби и т. д.)
- Потребляемая мощность
- Версия прошивки
- Аналитика для всего этого бизнеса
Также, определив уровень нагрузки на различное оборудование, нам удалось добиться улучшения распределения ресурсов.
В частности, энергопотребление.
Теперь мы можем принимать обоснованные решения о размещении сервера до его установки в стойку и подключения к источнику питания, на протяжении всего его жизненного цикла и до момента его окончательного выхода из эксплуатации.
Энергетическая панель в Grafana
А потом появился Covid-19.
Наша команда создает технологии, которые позволяют медиакомпаниям и издателям в Интернете помогать посетителям находить соответствующий контент, продукты и услуги, которые могут их заинтересовать.Наша инфраструктура предназначена для обслуживания трафика, генерируемого при выходе интересных новостей.
Интенсивное освещение в СМИ ситуации с COVID-19 в сочетании с увеличением трафика означало, что нам срочно нужно научиться справляться с этим давлением.
Причем все это пришлось делать во время мирового кризиса, когда цепочки поставок были нарушены и большая часть персонала находилась дома.
Но, как мы уже говорили, наша модель уже предполагает, что:
- Оборудование в наших дата-центрах по большей части нам физически недоступно;
- Почти всю физическую работу мы выполняем удаленно;
- Работа выполняется асинхронно, автономно и в больших масштабах;
- Потребность в оборудовании удовлетворяем методом «сборки из запчастей» вместо закупки нового оборудования;
- У нас есть склад, который позволяет нам создавать что-то новое, а не просто проводить текущий ремонт.
А что касается запчастей и серверов, да, мы постарались обеспечить стабильную работу оборудования.
Но сделано это с целью предотвратить возможные инциденты, когда вдруг окажется, что какая-то железка недоступна.
Мы добились того, чтобы наши резервы были заполнены без стремления удовлетворить текущий спрос.
Подводя итог, я хотел бы сказать, что наш подход к работе в индустрии центров обработки данных доказывает, что принципы хорошего дизайна кода можно применять к физическому управлению центром обработки данных.
И возможно, вам это будет интересно.
Оригинал: тыц Теги: #центр обработки данных #Системное администрирование #облачные сервисы #Администрирование серверов #Администрирование баз данных #администрирование #Grafana #Jira
-
Что Нового В Программировании На Python?
19 Oct, 24 -
Как Я Делал Hot-Spot Через Virtual Box
19 Oct, 24 -
Задача Из Школьной Олимпиады.
19 Oct, 24 -
Ibm Обновила По Для Управления Дата-Центрами
19 Oct, 24
