Привіт, Хабре! Представляю вашій увазі переклад статті автора Adib Daw.
Якщо цей заголовок не викликав легке тремтіння у хребті, вам слід перейти до наступного абзацу або перейти на нашу сторінку, присвячену - Ми хотіли б поговорити.
Хто ми
Ми команда з 4 пінгвінів, які люблять писати код та працювати з обладнанням. У вільний час ми відповідаємо за розгортання, обслуговування та експлуатацію парку з більш ніж 7000 фізичних серверів під управлінням Linux, розподілених по 3 різних дата-центрах на території США.
Нам також довелося займатися цим на відстані 10 000 км. від об'єктів, не виходячи з нашого власного кабінету, який розташований за кілька хвилин їзди від пляжу на Середземному морі.
Проблеми масштабу
Хоча для стартапу є сенс почати з розміщення своєї інфраструктури в хмарі через невеликі початкові інвестиції, ми в Outbrain вирішили використовувати свої власні сервери. Ми зробили так з тієї причини, що витрати на інфраструктуру хмар набагато перевищують витрати на експлуатацію власного обладнання, розміщеного в дата-центрах після розвитку до певного рівня. До того ж, свій сервер забезпечує найвищий ступінь контролю та можливостей усунення несправностей.
У міру того, як ми розвиваємось, проблеми завжди знаходяться поряд. Причому зазвичай приходять групами. Управління життєвим циклом сервера вимагає постійного самовдосконалення, щоб мати змогу нормально працювати за умов швидкого збільшення кількості серверів. Програмні методи управління серверними групами у центрах обробки даних дуже швидко стають громіздкими. Виявлення, усунення несправностей та усунення збоїв при забезпеченні норм, прописаних у договорі про якість обслуговування, перетворюється на маніпулювання надзвичайно різноманітними апаратними масивами, різними навантаженнями, термінами оновлення та іншими приємними речами, про які ніхто не хоче дбати.
Освойте свої Домени
Щоб вирішити багато цих проблем, ми розбили життєвий цикл сервера в Outbrain на його основні компоненти і назвали їх доменами. Наприклад, один домен охоплює потребу в обладнанні, інший – логістику, пов'язану з життєвим циклом запасів, а третій – зв'язок із персоналом на місці. Є ще один, що стосується апаратної спостережуваності, але ми не будемо розписувати всі моменти. Нашою метою було вивчення та визначення доменів, щоб їх можна було абстрагувати за допомогою коду. Як тільки робоча абстракція розроблена, вона переводиться в ручний процес, який розгортається, тестується та доопрацьовується. Нарешті, домен налаштований для інтеграції з іншими доменами через API, формуючи цілісну, динамічну систему життєвого циклу обладнання, що постійно розвивається, яка може бути розгорнута, тестована і спостерігається. Як і всі інші виробничі системи.
Прийняття такого підходу дозволило нам правильно вирішувати багато проблем шляхом створення інструментів і засобів автоматизації.
Домен потреб
Хоча email та електронні таблиці були прийнятним способом задоволення попиту в перші дні, це не можна було назвати вдалим рішенням, особливо коли кількість серверів та обсяг запитів, що входять, досягли певного рівня. Щоб краще організувати та розставити пріоритети запитів, що входять в умовах швидкого розширення, нам довелося використовувати систему тикетів, яка могла запропонувати:
- Можливість налаштування подання лише відповідних полів (простий)
- Відкриті API (розширюваний)
- Відомий нашій команді (зрозумілий)
- Інтегрованість із нашими існуючими робочими процесами (уніфікований)
Оскільки ми використовуємо Джиру для управління нашими спринтами та внутрішніми завданнями, то вирішили створити ще один проект, який допоміг би нашим клієнтам надсилати заявки та відстежувати їх результати. Використання Джири для вхідних запитів та управління внутрішніми завданнями дозволила нам створити єдину Канбан-дошку, яка дозволила нам поглянути всі процеси загалом. Наші внутрішні «клієнти» бачили лише заявки на обладнання, не вникаючи в менш значущі деталі додаткових завдань (наприклад, покращення інструментів, виправлення помилок).
Канбан-дошка в Джирі
Як бонус той факт, що черги та пріоритети тепер були видно всім, дозволяв зрозуміти, «де в черзі» знаходиться конкретний запит і що передувало йому. Це дозволяло власникам змінювати пріоритети у власних запитах без необхідності зв'язуватися з нами. Перетяг – і всіх діл. Це також дозволило нам моніторити та оцінювати наші SLA відповідно до типів запитів на основі показників, згенерованих у Джирі.
Домен життєвого циклу обладнання
Спробуйте уявити складність керування обладнанням, що використовується у кожній серверній стійці. Що ще гірше, багато залоз (RAM, ROM) можуть переміщатися зі складу в серверну і назад. А ще вони виходять з ладу або списуються та замінюються, повертаються постачальнику для заміни/ремонту. Все це потрібно повідомляти співробітників колокейшн-служби, які займаються фізичним обслуговуванням обладнання. Для вирішення цих проблем ми створили внутрішній інструмент Floppy. Його завдання в:
- управління зв'язком з персоналом на місцях, агрегація всієї інформації;
- Оновлення даних «складу» після кожної виконаної та перевіреної роботи з обслуговування обладнання.
Склад, своєю чергою, візуалізується за допомогою Grafana, яку ми використовуємо для побудови графіків усіх наших показників. Таким чином, ми використовуємо один і той же інструмент для візуалізації складу та інших виробничих потреб.
Панель керування обладнанням на складі у Grafana
Для серверних пристроїв, які знаходяться на гарантії, ми використовуємо інший інструмент, який ми назвали Dispatcher. Він:
- Збирає логі системи;
- Формує звіти у потрібному вендору форматі;
- Заводить заявку у вендора через API;
- Отримує та зберігає ідентифікатор заявки для подальшого відстеження її ходу.
Після того, як наша претензія приймається (як правило, це відбувається протягом робочого дня), запасна частина відправляється у відповідний ЦОД та приймається персоналом.
Виведення консолі Jenkins
Домен зв'язку
Щоб встигати за швидким зростанням бізнесу, що вимагає дедалі більшої ємності, нам довелося адаптувати під себе методи роботи з технічними фахівцями локальних центрів обробки даних. Якщо спочатку збільшення масштабу означало купівлю нових серверів, то після проекту консолідації (заснованого на перехід у Кубернетес) це стало чимось іншим. Наш розвиток із «додавання стійок» перетворився на «перепрофілювання серверів».
Використання нового підходу зажадало нових інструментів, що дозволяють з великим комфортом взаємодіяти з персоналом центрів обробки даних. Від цих інструментів вимагалася:
- Простота;
- Автономність;
- Ефективність;
- Надійність.
Нам довелося виключити себе з ланцюжка та побудувати роботу так, щоб техніки могли безпосередньо працювати серверним обладнанням. Без нашого втручання та без регулярного підняття всіх цих питань, що стосуються робочого навантаження, робочого часу, наявності обладнання та ін.
Щоб досягти цього, ми встановили iPad у кожному дата-центрі. Після підключення до сервера відбудеться таке:
- Пристрій підтверджує, що сервер дійсно вимагає проведення якихось робіт;
- Програми, запущені на сервері, закриваються (за потреби);
- Набір робочих інструкцій публікується на Slack з поясненням необхідних кроків;
- Після завершення роботи пристрій перевіряє коректність кінцевого стану сервера;
- За потреби перезапускає програми.
Крім цього, ми також підготували бот Slack, який би допомагав технічному спеціалісту. Завдяки широкому набору можливостей (ми постійно розширювали функціонал) бот зробив їхню роботу простіше, а нам здорово полегшив життя. Так ми оптимізували більшу частину процесу перепрофілювання та обслуговування серверів, виключивши себе з робочого процесу.
iPad в одному з наших центрів обробки даних
Домен апаратного забезпечення
Надійне масштабування інфраструктури нашого центру обробки даних вимагає хорошої видимості кожного компонента, наприклад:
- Виявлення збою у залозі
- Стан сервера (активний, розміщений, зомбі і т.д.)
- споживана потужність
- Версію прошивки
- Аналітика з усього цього господарства
Наші рішення дозволяють нам приймати рішення про те, як, де і коли купувати обладнання, іноді навіть до того, як у ньому реально виникне потреба. Також шляхом визначення рівня навантажень на різне обладнання ми змогли досягти покращення розподілу ресурсів. Зокрема, енергоспоживання. Тепер ми можемо приймати обґрунтовані рішення щодо розміщення сервера до того, як він буде встановлений у стійку та підключений до джерела живлення, а також протягом усього циклу експлуатації та аж до його можливого списання.
Панель енергоспоживання у Grafana
І тут з'явився COVID-19.
Наша команда створює технології, які розширюють можливості медіакомпаній та видавництв у мережі, допомагають відвідувачам знаходити релевантний контент, продукти та послуги, які можуть бути цікавими для них. Наша інфраструктура призначена для обслуговування трафіку, що генерується під час виходу якихось ажіотажних новин.
Активне висвітлення у ЗМІ подій, пов'язаних із COVID-19, у поєднанні з приростом трафіку означало, що нам необхідно було терміново навчитися справлятися з такими навантаженнями. До того ж, все це потрібно було зробити в умовах глобальної кризи, коли ланцюжки поставок були порушені, а більшість персоналу знаходилася вдома.
Але, як ми вже говорили, наша модель вже припускає, що:
- Обладнання в наших центрах обробки даних здебільшого фізично недоступне для нас;
- Ми виконуємо майже всю фізичну роботу віддалено;
- Робота виконується асинхронно, автономно та у великому обсязі;
- Ми задовольняємо попит обладнання методом «складання з деталей» замість купівлі нового устаткування;
- Ми маємо склад, який дозволяє створювати щось нове, а не просто виконувати поточний ремонт.
Таким чином, глобальні обмеження, які завадили багатьом компаніям отримати фізичний доступ до своїх центрів обробки даних, мало мало впливу на нас А щодо запчастин і серверів — так, ми намагалися забезпечити стабільну роботу обладнання. Але робилося з метою запобігти можливим казусам, коли раптово з'ясовується, що якоїсь «залізки» немає. Ми забезпечували наповнення наших резервів, не ставлячи за мету задоволення поточного попиту.
Як підсумок, я хотів би сказати, що наш підхід до роботи у сфері ЦОД доводить, що можна застосувати принципи хорошого проектування коду до процесів фізичного управління центром обробки даних. І, можливо, вам це здасться цікавим.
оригінал:
Джерело: habr.com