Хей Хабр! Представям на вашето внимание превода на статията от Адиб Доу.
Ако това заглавие не ви побива лека тръпка, трябва да преминете към следващия абзац или да посетите нашата страница, посветена на - бихме искали да поговорим.
Кои сме ние
Ние сме екип от 4 пингвина, които обичат да пишат код и да работят с хардуер. В свободното си време ние сме отговорни за внедряването, поддръжката и експлоатацията на флот от над 7000 физически сървъра, работещи с Linux, разпределени в 3 различни центъра за данни в Съединените щати.
Имахме и възможността да направим това на 10 000 км от обекти, от комфорта на нашия собствен офис, който се намира на кратко разстояние с кола от плажа на Средиземно море.
Проблеми с мащаба
Въпреки че има смисъл една стартираща компания да започне с хостване на своята инфраструктура в облака поради сравнително ниската първоначална инвестиция, ние от Outbrain решихме да използваме собствени сървъри. Направихме това, защото разходите за облачна инфраструктура далеч надвишават разходите за експлоатация на нашето собствено оборудване, разположено в центрове за данни след разработка до определено ниво. Освен това вашият сървър осигурява най-висока степен на контрол и възможности за отстраняване на проблеми.
Докато се развиваме, проблемите винаги са наблизо. Освен това те обикновено идват на групи. Управлението на жизнения цикъл на сървъра изисква постоянно самоусъвършенстване, за да може да функционира правилно в контекста на бързото нарастване на броя на сървърите. Софтуерните методи за управление на сървърни групи в центрове за данни бързо стават тромави. Откриването, отстраняването на неизправности и смекчаването на неуспехите при спазване на стандартите за QoS става въпрос на жонглиране с изключително разнообразни масиви от хардуер, различни натоварвания, крайни срокове за надграждане и други хубави неща, за които никой не иска да се тревожи.
Овладейте своите домейни
За да разрешим много от тези проблеми, ние разделихме жизнения цикъл на сървъра в Outbrain на неговите основни компоненти и ги нарекохме домейни. Например, един домейн покрива изискванията за оборудване, друг покрива логистиката, свързана с жизнения цикъл на инвентара, а трети обхваща комуникациите с персонала на място. Има още един, който се отнася до хардуерната наблюдаемост, но няма да описваме всички точки. Нашата цел беше да проучим и дефинираме домейни, така че да могат да бъдат абстрахирани с помощта на код. След като се разработи работеща абстракция, тя се прехвърля към ръчен процес, който се внедрява, тества и усъвършенства. И накрая, домейнът е конфигуриран да се интегрира с други домейни чрез API, образувайки холистична, динамична и непрекъснато развиваща се система за жизнения цикъл на хардуера, която може да се внедри, тества и наблюдава. Точно както всички други наши производствени системи.
Възприемането на този подход ни позволи да решим много проблеми правилно - чрез създаване на инструменти и автоматизация.
Нужен домейн
Въпреки че имейлът и електронните таблици бяха жизнеспособен начин за посрещане на търсенето в ранните дни, това не беше успешно решение, особено когато броят на сървърите и обемът на входящите заявки достигнаха определено ниво. За да организираме по-добре и приоритизираме входящите заявки в условията на бързо разрастване, трябваше да използваме система за билети, която можеше да предложи:
- Възможност за персонализиране на изгледа само на съответните полета (просто)
- Отворени API (разширяеми)
- Познат на нашия екип (разбрано)
- Интеграция с нашите съществуващи работни процеси (унифицирани)
Тъй като използваме Jira за управление на нашите спринтове и вътрешни задачи, решихме да създадем друг проект, който да помогне на нашите клиенти да изпращат билети и да проследяват резултатите си. Използването на Jira за входящи заявки и за управление на вътрешни задачи ни позволи да създадем единна Kanban дъска, която ни позволи да разгледаме всички процеси като цяло. Нашите вътрешни „клиенти“ виждаха само заявки за оборудване, без да се задълбочават в по-малко значимите подробности за допълнителни задачи (като подобряване на инструменти, коригиране на грешки).
Kanban дъска в Jira
Като бонус, фактът, че опашките и приоритетите вече са видими за всички, направи възможно да се разбере „къде в опашката“ е конкретна заявка и какво я предхожда. Това позволи на собствениците да приоритизират отново собствените си заявки, без да се налага да се свързват с нас. Плъзнете го и това е. Освен това ни позволи да наблюдаваме и оценяваме нашите SLA според типовете заявки въз основа на показателите, генерирани в Jira.
Домейн на жизнения цикъл на оборудването
Опитайте се да си представите сложността на управлението на хардуера, използван във всеки сървърен шкаф. Още по-лошото е, че много хардуерни части (RAM, ROM) могат да бъдат преместени от склада в сървърната стая и обратно. Те също се повредят или се отписват и заменят и се връщат на доставчика за подмяна/ремонт. Всичко това трябва да бъде съобщено на служителите на службата за колокация, участващи във физическата поддръжка на оборудването. За да разрешим тези проблеми, създадохме вътрешен инструмент, наречен Floppy. Неговата задача е:
- Управление на комуникациите с теренния персонал, обобщаване на цялата информация;
- Актуализиране на „складовите” данни след всяка изпълнена и проверена работа по поддръжката на оборудването.
Складът от своя страна се визуализира с помощта на Grafana, която използваме, за да начертаем всички наши показатели. По този начин ние използваме един и същ инструмент за складова визуализация и за други производствени нужди.
Табло за управление на складова техника в Графана
За сървърни устройства, които са в гаранция, ние използваме друг инструмент, който наричаме Dispatcher. Той:
- Събира системни регистрационни файлове;
- Генерира отчети във формат, изискван от доставчика;
- Създава заявка от доставчика чрез API;
- Получава и съхранява идентификатора на приложението за по-нататъшно проследяване на напредъка му.
След като рекламацията ни бъде приета (обикновено в рамките на работното време), резервната част се изпраща до съответния център за данни и се приема от персонала.
Конзолен изход на Jenkins
Комуникационен домейн
За да сме в крак с бързия растеж на нашия бизнес, който изисква непрекъснато нарастващ капацитет, трябваше да адаптираме начина, по който работим с техническите специалисти в местните центрове за данни. Ако първоначално мащабирането означаваше закупуване на нови сървъри, то след проект за консолидация (базиран на прехода към Kubernetes) стана нещо съвсем различно. Нашата еволюция от „добавяне на шкафове“ до „преназначение на сървъри“.
Използването на нов подход също изисква нови инструменти, които правят възможно по-удобното взаимодействие с персонала на центъра за данни. Тези инструменти бяха необходими за:
- простота;
- Автономия;
- Ефективност;
- Надеждност.
Трябваше да се изключим от веригата и да структурираме работата така, че техниците да работят директно със сървърното оборудване. Без нашата намеса и без редовно да повдигаме всички тези въпроси относно натовареност, работно време, наличност на оборудване и т.н.
За да постигнем това, инсталирахме iPad във всеки център за данни. След свързване със сървъра ще се случи следното:
- Устройството потвърждава, че този сървър наистина изисква известна работа;
- Приложенията, работещи на сървъра, се затварят (ако е необходимо);
- Набор от инструкции за работа е публикуван в канал Slack, обясняващ необходимите стъпки;
- След приключване на работата, устройството проверява коректността на крайното състояние на сървъра;
- Рестартира приложенията, ако е необходимо.
Освен това подготвихме и Slack бот в помощ на техника. Благодарение на широка гама от възможности (ние непрекъснато разширявахме функционалността), ботът улесни работата им и направи живота ни много по-лесен. По този начин оптимизирахме по-голямата част от процеса на пренасочване и поддръжка на сървъри, елиминирайки себе си от работния процес.
iPad в един от нашите центрове за данни
Хардуерен домейн
Надеждното мащабиране на инфраструктурата на нашия център за данни изисква добра видимост на всеки компонент, например:
- Откриване на хардуерен срив
- Състояния на сървъра (активен, хостван, зомби и т.н.)
- Консумация на електроенергия
- Версия на фърмуера
- Анализ за целия този бизнес
Нашите решения ни позволяват да вземаме решения за това как, къде и кога да закупим оборудване, понякога дори преди действително да е необходимо. Също така, чрез определяне на нивото на натоварване на различно оборудване, успяхме да постигнем подобрено разпределение на ресурсите. По-специално консумацията на енергия. Вече можем да вземаме информирани решения относно разположението на сървър, преди да бъде инсталиран в шкафа и свързан към източник на захранване, през целия му жизнен цикъл и до евентуалното му оттегляне.
Energy Dashboard в Графана
И тогава се появи COVID-19...
Нашият екип създава технологии, които дават възможност на медийните компании и издателите онлайн да помагат на посетителите да намират подходящо съдържание, продукти и услуги, които може да представляват интерес за тях. Нашата инфраструктура е проектирана да обслужва трафик, генериран при публикуване на вълнуващи новини.
Интензивното медийно отразяване около COVID-19, съчетано с увеличаването на трафика, означаваше, че трябва спешно да се научим как да се справяме с този натиск. Освен това всичко това трябваше да се направи по време на глобална криза, когато веригите за доставки бяха нарушени и повечето от персонала бяха у дома.
Но, както казахме, нашият модел вече предполага, че:
- Оборудването в нашите центрове за данни в по-голямата си част е физически недостъпно за нас;
- Извършваме почти цялата физическа работа дистанционно;
- Работата се извършва асинхронно, автономно и в голям мащаб;
- Ние посрещаме търсенето на оборудване по метода „изгради от части“, вместо да закупуваме ново оборудване;
- Разполагаме със склад, който ни позволява да създадем нещо ново, а не само да извършваме рутинни ремонти.
По този начин глобалните ограничения, които попречиха на много компании да получат физически достъп до своите центрове за данни, ни повлияха малко.А що се отнася до резервните части и сървърите, да, опитахме се да осигурим стабилна работа на оборудването. Но това беше направено с цел предотвратяване на възможни инциденти, когато внезапно се окаже, че някакъв хардуер не е наличен. Ние гарантирахме, че резервите ни са запълнени, без да се стремим да отговорим на текущото търсене.
В обобщение бих искал да кажа, че нашият подход към работата в индустрията на центрове за данни доказва, че е възможно да се приложат принципите на добър дизайн на код към физическото управление на център за данни. И може би ще ви бъде интересно.
оригинал:
Източник: www.habr.com