Прывітанне, Хабр! Уяўляю вашай увазе пераклад артыкула аўтара Adib Daw.
Калі гэты загаловак не выклікаў лёгкую дрыготку ў хрыбетніку, вам трэба перайсці да наступнага абзаца або перайсці на нашу старонку, прысвечаную - Мы хацелі б пагаварыць.
хто мы
Мы каманда з 4 пінгвінаў, якія любяць пісаць код і працаваць з абсталяваннем. У вольны час мы адказваем за разгортванне, абслугоўванне і эксплуатацыю парка з больш за 7000 фізічных сервераў пад кіраваннем Linux, размеркаваных па 3 розных дата-цэнтрах на тэрыторыі ЗША.
Нам таксама давялося займацца гэтым на адлегласці 10 км ад аб'ектаў, не выходзячы з нашага ўласнага кабінета, які размешчаны ў некалькіх хвілінах язды ад пляжу на Міжземным моры.
Праблемы маштабу
Хоць для стартапа мае сэнс пачаць з размяшчэння сваёй інфраструктуры ў воблаку з-за адносна невялікіх першапачатковых інвестыцый, мы ў 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