Szia Habr! Figyelmébe ajánlom a cikk fordítását írta: Adib Daw.
Ha ettől a címsortól nem jön ki enyhe borzongás a gerinceden, ugorj a következő bekezdésre, vagy látogass el oldalunkra - szeretnénk beszélgetni.
Ki vagyunk
Mi egy 4 fős pingvin csapat vagyunk, akik szeretnek kódot írni és hardverrel dolgozni. Szabadidőnkben több mint 7000 Linuxot futtató fizikai szerverből álló flotta telepítéséért, karbantartásáért és üzemeltetéséért vagyunk felelősek, amelyek 3 különböző adatközpontban vannak elosztva szerte az Egyesült Államokban.
Lehetőségünk volt erre 10 000 km-re a helyszínektől, saját irodánk kényelméből, amely rövid autóútra található a Földközi-tenger partjától.
Méretezési problémák
Míg a viszonylag alacsony kezdeti befektetés miatt ésszerű, hogy egy induló vállalkozás infrastruktúráját felhőben tárolja, mi, az Outbrainnél úgy döntöttünk, hogy saját szervereinket használjuk. Ezt azért tettük, mert a felhő infrastruktúra költségei egy bizonyos szintig jóval meghaladják az adatközpontokban elhelyezett saját berendezéseink üzemeltetésének költségeit. Ezen túlmenően az Ön szervere a legmagasabb szintű vezérlési és hibaelhárítási lehetőségeket biztosítja.
Ahogy fejlődünk, a problémák mindig a közelben vannak. Ráadásul általában csoportosan érkeznek. A szerverek életciklus-kezelése folyamatos önfejlesztést igényel, hogy megfelelően tudjon működni a kiszolgálók számának rohamos növekedése mellett. Az adatközpontok szervercsoportjainak kezelésére szolgáló szoftveres módszerek gyorsan nehézkessé válnak. A QoS-szabványoknak való megfelelés mellett a hibák észlelése, hibaelhárítása és mérséklése a hardverek rendkívül változatos tömbjeivel, a változó terhelésekkel, a frissítési határidőkkel és más jó dolgokkal való zsonglőrré válik, amelyek miatt senki sem akar aggódni.
Sajátítsa el domainjeit
Számos probléma megoldása érdekében az Outbrain szerver életciklusát fő összetevőire bontottuk, és tartományoknak neveztük el őket. Például az egyik terület a felszerelési követelményeket, a másik a készlet életciklusához kapcsolódó logisztikát, a harmadik pedig a helyszíni személyzettel való kommunikációt fedi le. Van még egy a hardveres megfigyelhetőségről, de nem írunk le minden pontot. Célunk az volt, hogy tanulmányozzuk és definiáljuk a tartományokat, hogy azokat kód segítségével absztrahálni lehessen. A működő absztrakció kifejlesztése után egy kézi folyamatba kerül, amelyet telepítenek, tesztelnek és finomítanak. Végül a tartomány úgy van beállítva, hogy API-kon keresztül integrálódjon más tartományokkal, így egy holisztikus, dinamikus és folyamatosan fejlődő hardver életciklus-rendszert alkot, amely telepíthető, tesztelhető és megfigyelhető. Csakúgy, mint az összes többi termelési rendszerünk.
Ennek a megközelítésnek az alkalmazása lehetővé tette számos probléma helyes megoldását – eszközök és automatizálás révén.
Domain kell
Bár az e-mailek és a táblázatok a kezdeti időkben járható módja volt a kereslet kielégítésének, ez nem volt sikeres megoldás, különösen akkor, amikor a szerverek száma és a beérkező kérések mennyisége elért egy bizonyos szintet. A bejövő kérések jobb megszervezéséhez és rangsorolásához a gyors terjeszkedéssel szemben olyan jegyrendszert kellett használnunk, amely a következőket kínálta:
- Csak a releváns mezők nézetének testreszabása (egyszerű)
- Nyitott API-k (bővíthető)
- Csapatunk számára ismert (értett)
- Integráció meglévő munkafolyamatainkkal (egységesített)
Mivel a Jira-t használjuk sprintjeink és belső feladataink kezelésére, úgy döntöttünk, hogy létrehozunk egy másik projektet, amely segít ügyfeleinknek a jegyek benyújtásában és az eredmények nyomon követésében. A Jira használata a bejövő kérésekhez és a belső feladatok kezeléséhez lehetővé tette számunkra, hogy egyetlen Kanban táblát hozzunk létre, amely lehetővé tette az összes folyamat egészét. Belső „ügyfeleink” csak eszközigényeket láttak, anélkül, hogy a további feladatok (például eszközök fejlesztése, hibák javítása) kevésbé jelentős részleteibe belemélyedtek volna.
Kanban tábla Jira-ban
Bónuszként az a tény, hogy a sorok és a prioritások mostantól mindenki számára láthatóak voltak, lehetővé tette, hogy megértsék, „hol van a sorban” egy adott kérés, és mi előzte meg azt. Ez lehetővé tette a tulajdonosok számára, hogy átállítsák saját kéréseiket anélkül, hogy kapcsolatba kellett volna lépniük velünk. Húzza és ennyi. Lehetővé tette továbbá, hogy a Jira-ban generált mérőszámok alapján kéréstípusok szerint figyeljük és értékeljük SLA-jainkat.
Berendezés életciklus tartománya
Próbálja elképzelni, milyen bonyolult az egyes szerverállványokban használt hardverek kezelése. Ami még rosszabb, hogy sok hardver (RAM, ROM) mozgatható a raktárból a szerverterembe és vissza. Ezenkívül meghibásodnak vagy leírják, kicserélik, és visszaküldik a szállítónak csere/javítás céljából. Mindezt közölni kell a berendezés fizikai karbantartásában részt vevő kolokációs szolgálat munkatársaival. E problémák megoldására létrehoztunk egy Floppy nevű belső eszközt. Az ő feladata:
- A helyszíni személyzettel való kommunikáció kezelése, minden információ összesítése;
- A „raktár” adatok frissítése minden elvégzett és ellenőrzött berendezés-karbantartási munka után.
A raktárt pedig a Grafana segítségével vizualizáljuk, amelyet az összes mérőszámunk ábrázolására használunk. Így ugyanazt az eszközt használjuk a raktárvizualizációhoz és egyéb termelési igényekhez.
Raktári berendezések vezérlőpultja Grafanában
A garanciális szervereszközökhöz egy másik eszközt használunk, amelyet Dispatchernek hívunk. Ő:
- Rendszernaplókat gyűjt;
- Jelentéseket készít a szállító által megkövetelt formátumban;
- Kérést hoz létre a szállítótól API-n keresztül;
- Fogja és tárolja az alkalmazás azonosítóját az előrehaladás további nyomon követése érdekében.
Igényünk elfogadása után (általában munkaidőn belül) a pótalkatrészt elküldik a megfelelő adatközpontba, és a munkatársak elfogadják.
Jenkins konzol kimenet
Kommunikációs tartomány
Ahhoz, hogy lépést tudjunk tartani üzletünk rohamos növekedésével, amely egyre nagyobb kapacitást igényel, át kellett alakítanunk a helyi adatközpontokban dolgozó műszaki szakemberekkel való együttműködést. Ha eleinte a skálázás új szerverek vásárlását jelentette, akkor egy konszolidációs projekt után (a Kubernetesre való átállás alapján) egészen más lett. Fejlődésünk az „állványok hozzáadásától” a „kiszolgálók újrahasznosításáig”.
Az új megközelítés alkalmazása új eszközöket is igényelt, amelyek lehetővé tették az adatközponti személyzettel való kényelmesebb interakciót. Ezekre az eszközökre volt szükség:
- Egyszerűség;
- Autonómia;
- Hatékonyság;
- Megbízhatóság.
Ki kellett zárnunk magunkat a láncból, és úgy kellett strukturálni a munkát, hogy a technikusok közvetlenül dolgozhassanak szerverberendezésekkel. A mi beavatkozásunk nélkül, és anélkül, hogy rendszeresen felvetnénk ezeket a kérdéseket a munkaterheléssel, a munkaidővel, a berendezések rendelkezésre állásával stb.
Ennek érdekében minden adatközpontba iPadet telepítettünk. A szerverhez való csatlakozás után a következő történik:
- Az eszköz megerősíti, hogy ez a szerver valóban igényel némi munkát;
- A szerveren futó alkalmazások zárva vannak (ha szükséges);
- A szükséges lépéseket ismertető munkautasítások egy Slack csatornán találhatók;
- A munka befejeztével az eszköz ellenőrzi a szerver végső állapotának helyességét;
- Szükség esetén újraindítja az alkalmazásokat.
Ezen kívül egy Slack botot is készítettünk a technikus segítségére. A sokféle képességnek köszönhetően (folyamatosan bővítettük a funkcionalitást) a bot megkönnyítette a munkájukat, és nagyban megkönnyítette az életünket. Így optimalizáltuk a szerverek újrahasznosítási és karbantartási folyamatának nagy részét, kiiktatva magunkat a munkafolyamatból.
iPad az egyik adatközpontunkban
Hardver Domain
Adatközponti infrastruktúránk megbízható méretezéséhez az egyes összetevők jó láthatósága szükséges, például:
- Hardverhiba észlelése
- Szerver állapotok (aktív, hostolt, zombi stb.)
- Teljesítményfelvétel
- Firmware verzió
- Az egész vállalkozás elemzése
Megoldásaink lehetővé teszik számunkra, hogy döntéseket hozzunk arról, hogyan, hol és mikor vásároljunk felszerelést, néha még azelőtt, hogy ténylegesen szükség lenne rá. Ezenkívül a különböző berendezések terhelési szintjének meghatározásával jobb erőforrás-allokációt tudtunk elérni. Különösen az energiafogyasztás. Most már megalapozott döntéseket hozhatunk a szerver elhelyezésével kapcsolatban, mielőtt azt a rackbe telepítenék és áramforráshoz csatlakoztassanak, teljes életciklusa alatt, és egészen a végleges kivonásig.
Energy Dashboard a Grafana-ban
Aztán megjelent a COVID-19...
Csapatunk olyan technológiákat hoz létre, amelyek lehetővé teszik a médiavállalatok és kiadók online lehetőségét, hogy segítsenek a látogatóknak megtalálni a számukra érdekes tartalmat, termékeket és szolgáltatásokat. Infrastruktúránk úgy van kialakítva, hogy kiszolgálja a forgalmat, amikor izgalmas hírek kerülnek nyilvánosságra.
A COVID-19 körüli intenzív médiavisszhang, valamint a forgalom növekedése azt jelentette, hogy sürgősen meg kell tanulnunk megbirkózni ezekkel a nyomásokkal. Ráadásul mindezt egy globális válság idején kellett megtenni, amikor az ellátási láncok megszakadtak, és a személyzet nagy része otthon volt.
De mint mondtuk, modellünk már feltételezi, hogy:
- Adatközpontjaink berendezései többnyire fizikailag hozzáférhetetlenek számunkra;
- Szinte minden fizikai munkát távolról végzünk;
- A munkavégzés aszinkron módon, önállóan és nagy léptékben történik;
- A berendezések iránti igényeket új berendezések beszerzése helyett "alkatrészből építkezzünk" módszerrel elégítjük ki;
- Van egy raktárunk, amely lehetővé teszi, hogy ne csak rutinjavításokat hajtsunk végre, hanem új dolgokat alkossunk.
Így azok a globális korlátozások, amelyek sok céget akadályoztak abban, hogy fizikailag hozzáférjenek adatközpontjaihoz, nemigen voltak ránk hatással, az alkatrészek és szerverek tekintetében pedig igen, igyekeztünk biztosítani a berendezések stabil működését. De ezt azzal a céllal tették, hogy megakadályozzák az esetleges incidenseket, amikor hirtelen kiderül, hogy valamelyik hardver nem elérhető. Gondoskodtunk arról, hogy tartalékainkat az aktuális igények kielégítése nélkül töltsük fel.
Összefoglalva azt szeretném elmondani, hogy az adatközpont-iparban való munkavégzésünkhöz való hozzáállásunk azt bizonyítja, hogy lehetséges a jó kódtervezés alapelveit alkalmazni egy adatközpont fizikai menedzselésére. És talán érdekesnek fogod találni.
eredeti:
Forrás: will.com