Sziasztok. Vezető rendszergazdaként dolgozom az OK-nál, és a portál stabil működéséért felelek. Arról szeretnék beszélni, hogyan építettünk fel egy folyamatot a lemezek automatikus cseréjére, majd hogyan zártuk ki ebből a folyamatból az adminisztrátort, és egy bottal helyettesítettük.
Ez a cikk egyfajta átírás a HighLoad+ 2018-ban
Lemezcsere folyamat felépítése
Először néhány szám
Az OK egy óriási szolgáltatás, amelyet emberek milliói használnak. Körülbelül 7 ezer szerver szolgálja ki, amelyek 4 különböző adatközpontban helyezkednek el. A szerverek több mint 70 ezer lemezt tartalmaznak. Ha egymásra rakod őket, egy 1 km-nél magasabb tornyot kapsz.
A merevlemezek a leggyakrabban meghibásodó szerverkomponensek. Ilyen mennyiségeknél körülbelül 30 lemezt kell cserélnünk hetente, és ez az eljárás nem túl kellemes rutinná vált.
Incidensek
Cégünk bevezette a teljes körű incidenskezelést. Minden incidenst rögzítünk Jira-ban, majd megoldjuk és rendezzük. Ha egy incidens hatással volt a felhasználókra, akkor mindenképpen összeülünk, és átgondoljuk, hogyan lehet ilyen esetekben gyorsabban reagálni, hogyan csökkenthetjük a hatást, és persze hogyan lehet megelőzni a megismétlődést.
A tárolóeszközök sem kivételek. Állapotukat a Zabbix figyeli. Figyeljük a Syslog üzeneteit írási/olvasási hibák miatt, elemezzük a HW/SW raidek állapotát, figyeljük a SMART-ot, és kiszámítjuk az SSD-k kopását.
Hogyan cserélték ki korábban a lemezeket
Amikor egy trigger történik a Zabbix rendszerben, egy incidens jön létre a Jira-ban, és automatikusan hozzárendeli a megfelelő mérnökökhöz az adatközpontokban. Ezt minden HW incidensnél megtesszük, vagyis azokkal, amelyek bármilyen fizikai munkát igényelnek az adatközpont berendezéseivel.
Az adatközponti mérnök az a személy, aki megoldja a hardverrel kapcsolatos problémákat, és felelős a szerverek telepítéséért, karbantartásáért és szétszereléséért. Miután megkapta a jegyet, a mérnök munkához lát. A lemezpolcokon önállóan cseréli a lemezeket. De ha nem fér hozzá a szükséges eszközhöz, a mérnök az ügyeletes rendszergazdákhoz fordul segítségért. Először is el kell távolítania a lemezt a forgásból. Ehhez el kell végeznie a szükséges változtatásokat a kiszolgálón, le kell állítania az alkalmazásokat, és le kell választania a lemezt.
A teljes portál működéséért az ügyeletes rendszergazda a felelős a műszak alatt. Kivizsgálja az eseményeket, javításokat végez, és segít a fejlesztőknek kisebb feladatok elvégzésében. Nem csak merevlemezekkel foglalkozik.
Korábban az adatközpont mérnökei chaten kommunikáltak a rendszergazdával. A mérnökök linkeket küldtek a Jira jegyekhez, az adminisztrátor követte őket, és valamilyen jegyzettömbben naplót vezetett a munkáról. A csevegés azonban kényelmetlen az ilyen feladatokhoz: az ott található információ nem strukturált, és gyorsan elveszik. Az adminisztrátor pedig egyszerűen elsétálhat a számítógéptől, és egy ideig nem válaszolt a kérésekre, miközben a mérnök a szervernél állt egy köteg lemezzel és várt.
De a legrosszabb az volt, hogy az adminisztrátorok nem látták a teljes képet: milyen lemezincidensek léteznek, hol merülhet fel probléma. Ez annak köszönhető, hogy az összes HW eseményt mérnökökre ruházzuk át. Igen, az összes eseményt meg lehetett jeleníteni a rendszergazda műszerfalán. De nagyon sok van belőlük, és az adminisztrátor csak néhányukhoz volt bevonva.
Ráadásul a mérnök nem tudta helyesen beállítani a prioritásokat, mert semmit sem tud az adott szerverek céljáról vagy az információk meghajtók közötti elosztásáról.
Új csere eljárás
Először az összes lemezes incidenst áthelyeztük egy külön típusú „HW disk”-be, és hozzáadtuk a „blokk eszköznév”, „méret” és „lemeztípus” mezőket, hogy ezek az információk a jegyben tárolódnak, és nem kell állandóan cserélgetni a chaten.
Abban is megegyeztünk, hogy egy esemény során csak egy lemezt cserélünk. Ez jelentősen leegyszerűsítette az automatizálási folyamatot, a statisztikák gyűjtését és a jövőbeni munkát.
Ezenkívül hozzáadtuk a „felelős rendszergazda” mezőt. Az ügyeletes rendszergazda automatikusan bekerül oda. Ez nagyon kényelmes, mert most a mérnök mindig látja, ki a felelős. Nem kell a naptárhoz menni és keresgélni. Ez a mező tette lehetővé a jegyek megjelenítését az adminisztrátor műszerfalán, amelyekhez szükség lehet a segítségére.
Annak érdekében, hogy minden résztvevő maximális előnyhöz jusson az innovációkból, szűrőket és irányítópultokat hoztunk létre, és tájékoztattuk a srácokat róluk. Amikor az emberek megértik a változásokat, nem határolódnak el tőlük, mint valami szükségtelentől. Fontos, hogy egy mérnök ismerje a rack számát, ahol a szerver található, a lemez méretét és típusát. Az adminisztrátornak mindenekelőtt meg kell értenie, hogy milyen szervercsoportról van szó, és milyen hatással lehet egy lemez cseréje.
A mezők jelenléte és megjelenítése kényelmes, de nem mentett meg minket a chat használatától. Ehhez meg kellett változtatnunk a munkafolyamatot.
Korábban ez így volt:
A mérnökök így dolgoznak ma is, amikor nincs szükségük rendszergazdai segítségre.
Az első dolgunk egy új státusz bevezetése volt Vizsgáljuk. A jegy akkor van ebben az állapotban, ha a mérnök még nem döntötte el, hogy szüksége lesz-e rendszergazdára vagy sem. Ezen az állapoton keresztül a mérnök átadhatja a jegyet az adminisztrátornak. Ezenkívül ezt az állapotot használjuk a jegyek megjelölésére, ha egy lemezt cserélni kell, de maga a lemez nincs a helyszínen. Ez CDN-ek és távoli helyek esetén történik.
Az állapotot is hozzáadtuk Kész. A jegy a lemez cseréje után átkerül rá. Azaz már minden megtörtént, de a HW/SW RAID szinkronizálva van a szerveren. Ez elég sokáig tarthat.
Ha egy rendszergazda is részt vesz a munkában, akkor a séma kissé bonyolultabbá válik.
Állapotból Nyisd ki A jegyet a rendszergazda és a mérnök is lefordíthatja. Állapotban Folyamatban az adminisztrátor eltávolítja a lemezt a forgásból, hogy a mérnök egyszerűen ki tudja húzni: bekapcsolja a háttérvilágítást, leválasztja a lemezt, leállítja az alkalmazásokat, az adott szervercsoporttól függően.
A jegy ezután átkerül a Készen áll a változásra: Ez egy jelzés a mérnöknek, hogy a lemezt ki lehet húzni. A Jira minden mezője már ki van töltve, a mérnök tudja, milyen típusú és méretű lemez. Ezeket az adatokat vagy automatikusan az előző állapotba, vagy az adminisztrátor adja meg.
A lemez cseréje után a jegy állapota erre módosul megváltozott. Ellenőrzi, hogy a megfelelő lemezt helyezték-e be, a particionálás megtörtént, az alkalmazás elindul, és elindul néhány adat-helyreállítási feladat. A jegy státuszba is átvihető Kész, ebben az esetben az adminisztrátor marad a felelős, mert ő helyezte forgásba a lemezt. A teljes diagram így néz ki.
Új mezők hozzáadása jelentősen megkönnyítette az életünket. A srácok strukturált információkkal kezdtek dolgozni, világossá vált, mit kell tenni és melyik szakaszban. A prioritások sokkal relevánsabbak lettek, mivel ezeket most az adminisztrátor határozza meg.
Nincs szükség csevegésre. Természetesen az adminisztrátor írhat a mérnöknek, hogy "ezt gyorsabban kell cserélni", vagy "már este van, lesz időd kicserélni?" De már nem kommunikálunk naponta chaten ezekről a kérdésekről.
A lemezeket tételesen kezdték cserélni. Ha az adminisztrátor egy kicsit korán érkezett dolgozni, van szabad ideje, és még nem történt semmi, számos szervert fel tud készíteni a cserére: töltse ki a mezőket, távolítsa el a lemezeket a forgásból, és adja át a feladatot egy mérnöknek. A mérnök kicsit később érkezik az adatközpontba, látja a feladatot, kiveszi a raktárból a szükséges meghajtókat és azonnal kicseréli. Ennek eredményeként nőtt a cserearány.
A Workflow felépítése során levont tanulságok
- Egy eljárás felépítése során információkat kell gyűjtenie különböző forrásokból.
Néhány rendszergazdánk nem tudta, hogy a mérnök maga cseréli ki a lemezeket. Egyesek úgy gondolták, hogy az MD RAID szinkronizálást mérnökök oldották meg, pedig néhányan még csak nem is fértek hozzá. Néhány vezető mérnök megtette ezt, de nem mindig, mert a folyamatot sehol nem írták le. - Az eljárásnak egyszerűnek és érthetőnek kell lennie.
Az embernek nehéz sok lépést észben tartania. A Jira legfontosabb szomszédos állapotait a főképernyőn kell elhelyezni. Átnevezheti őket, például a Változásra késznek nevezzük. Más állapotok pedig elrejthetők egy legördülő menüben, hogy ne bántsák a szemet. De jobb, ha nem korlátozzuk az embereket, hanem lehetőséget adunk nekik az átállásra.
Magyarázza el az innováció értékét. Amikor az emberek megértik, jobban elfogadják az új eljárást. Nagyon fontos volt számunkra, hogy az emberek ne kattintsanak végig a folyamaton, hanem kövessék azt. Aztán erre építettük az automatizálást. - Várjon, elemezze, találja ki.
Körülbelül egy hónapba telt az eljárás kidolgozása, a technikai megvalósítás, a találkozók és a megbeszélések. A megvalósítás pedig több mint három hónapot vesz igénybe. Láttam, hogy az emberek lassan elkezdik használni az innovációt. A kezdeti szakaszban sok volt a negatívum. De ez teljesen független volt magától az eljárástól és annak technikai megvalósításától. Például az egyik rendszergazda nem a Jira-t, hanem a Confluence Jira beépülő modulját használta, és néhány dolog nem volt elérhető számára. Megmutattuk neki Jira-t, és az adminisztrátor termelékenysége nőtt mind az általános feladatok, mind a lemezek cseréje során.
Lemezcsere automatizálása
Többször megkerestük a lemezcsere automatizálását. Voltak már fejlesztéseink és szkriptjeink, de ezek mind interaktívan vagy manuálisan működtek, és indítást igényeltek. És csak az új eljárás bevezetése után vettük észre, hogy pontosan ez hiányzik.
Mivel most a cserefolyamatunk szakaszokra van felosztva, amelyek mindegyikének egy adott végrehajtója és egy műveletlistája van, az automatizálást szakaszosan, és nem egyszerre tudjuk engedélyezni. Például a legegyszerűbb szakasz - Ready (RAID/adatszinkronizálás ellenőrzése) könnyen delegálható egy botra. Amikor a bot egy keveset tanult, adhatsz neki egy fontosabb feladatot - a lemez forgatása stb.
Állatkerti beállítások
Mielőtt a botról beszélnénk, tegyünk egy rövid kirándulást állatkertünkbe. Mindenekelőtt infrastruktúránk gigantikus méretének köszönhető. Másodszor, igyekszünk minden szolgáltatáshoz kiválasztani az optimális hardverkonfigurációt. Körülbelül 20 hardveres RAID modellünk van, többnyire LSI és Adaptec, de vannak HP és DELL különböző verziói is. Minden RAID-vezérlőnek saját felügyeleti segédprogramja van. A parancsok halmaza és kiadása az egyes RAID-vezérlők esetében verziónként eltérő lehet. Ha nem használ HW-RAID-et, ott az mdraid is használható.
Szinte minden új telepítést lemezes biztonsági mentés nélkül végzünk. Igyekszünk többé nem hardveres és szoftveres RAID-et használni, mivel rendszereinkről adatközponti szinten készítünk biztonsági másolatot, nem szerverek szintjén. De természetesen sok örökölt szervert kell támogatni.
Valahol a RAID-vezérlőkben lévő lemezeket nyers eszközökre, hol JBOD-okat használnak. A szerverben egy rendszerlemezes konfigurációk vannak, és ha azt cserélni kell, akkor újra kell telepíteni a szervert az operációs rendszer és az azonos verziójú alkalmazások telepítésével, majd hozzáadni a konfigurációs fájlokat, elindítani az alkalmazásokat. Sok olyan szervercsoport is létezik, ahol a biztonsági mentés nem a lemez alrendszer szintjén történik, hanem közvetlenül magukban az alkalmazásokban.
Összesen több mint 400 egyedi szervercsoportunk van, amelyek közel 100 különböző alkalmazást futtatnak. Ahhoz, hogy ilyen nagyszámú lehetőséget lefedjünk, szükségünk volt egy többfunkciós automatizálási eszközre. Lehetőleg egyszerű DSL-lel, hogy ne csak az tudja támogatni aki írta.
Azért választottuk az Ansible-t, mert ügynök nélküli: nem kellett infrastruktúra előkészítése, gyors indulás. Ráadásul Python nyelven írják, amit szabványként fogadnak el a csapaton belül.
Általános rendszer
Nézzük meg az általános automatizálási sémát, példaként egy eseményt használva. A Zabbix észleli, hogy az sdb lemez meghibásodott, a trigger világít, és jegy jön létre a Jira-ban. Az adminisztrátor megnézte, rájött, hogy ez nem másodpéldány és nem hamis pozitív, vagyis lemezt kell cserélni, és áttette a jegyet a Folyamatban lévőbe.
A Python nyelven írt DiskoBot alkalmazás rendszeresen lekérdezi a Jira-t új jegyekért. Észreveszi, hogy megjelent egy új Folyamatban jegy, elindul a megfelelő szál, ami elindítja a játékkönyvet az Ansible-ben (ez minden Jira állapotnál megtörténik). Ebben az esetben a Prepare2change elindul.
Az Ansible elküldi a gazdagépnek, eltávolítja a lemezt a forgásból, és visszahívásokon keresztül jelenti az állapotot az alkalmazásnak.
Az eredmények alapján a bot automatikusan áthelyezi a jegyet a Ready to change-re. A mérnök értesítést kap, és elmegy lemezt cserélni, majd átadja a jegyet a Changed-nek.
A fent leírt séma szerint a jegy visszakerül a bothoz, amely elindít egy másik játékkönyvet, a gazdagéphez kerül, és forgatásba helyezi a lemezt. A bot lezárja a jegyet. Hurrá!
Most beszéljünk a rendszer néhány összetevőjéről.
Diskobot
Ez az alkalmazás Python nyelven íródott. A JQL szerint választja ki a Jira jegyeit. Ez utóbbi a jegy állapotától függően a megfelelő kezelőhöz kerül, amely viszont elindítja az állapotnak megfelelő Ansible playbookot.
A JQL és a lekérdezési intervallumok az alkalmazás konfigurációs fájljában vannak meghatározva.
jira_states:
investigate:
jql: '… status = Open and "Disk Size" is EMPTY'
interval: 180
inprogress:
jql: '… and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
ready:
jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
interval: 7200
Például a Folyamatban állapotú jegyek közül csak azok vannak kijelölve, amelyeknél a Lemezméret és az Eszköznév mezők vannak kitöltve. Az eszköznév a játékkönyv végrehajtásához szükséges blokkeszköz neve. A lemez méretére azért van szükség, hogy a mérnök tudja, mekkora lemezre van szükség.
A Ready állapotú jegyek közül pedig kiszűrésre kerülnek a dbot_ignore címkével ellátott jegyek. A Jira címkéket egyébként mind az ilyen szűrésre, mind a jegyek duplikált jelölésére, statisztikai adatok gyűjtésére használjuk.
Ha egy játékkönyv meghibásodik, a Jira hozzárendeli a dbot_failed címkét, hogy később rendezhető legyen.
Interoperabilitás az Ansible-vel
Az alkalmazás az Ansible segítségével kommunikál . A playbook_executor-nak átadjuk a fájl nevét és egy változókészletet. Ez lehetővé teszi, hogy az Ansible projektet normál yml-fájlok formájában tartsa meg, ahelyett, hogy Python-kóddal írja le.
Szintén az Ansible-ben az *extra_vars*-on keresztül a blokkeszköz neve, a jegy állapota, valamint a callback_url, amely tartalmazza a kiadási kulcsot – ez a HTTP-ben a visszahívásra szolgál.
Minden indításkor egy ideiglenes leltár jön létre, amely egy gazdagépből és abból a csoportból áll, amelyhez ez a gazdagép tartozik, így a group_vars alkalmazásra kerül.
Íme egy példa egy HTTP-visszahívást megvalósító feladatra.
A playbookok visszahívás(ok) segítségével történő végrehajtásának eredményét kapjuk. Két típusuk van:
- , a játékkönyv-végrehajtás eredményeiről szolgáltat adatokat. Leírja az elindított, sikeresen vagy sikertelenül végrehajtott feladatokat. Ezt a visszahívást a rendszer akkor hívja meg, amikor a játékkönyv lejátszása befejeződött.
- HTTP visszahívás információk fogadásához játékkönyv lejátszása közben. Az Ansible feladatban POST/GET kérést hajtunk végre az alkalmazásunkhoz.
A változók átadása HTTP-visszahívás(ok)on keresztül történik, amelyeket a playbook végrehajtása során határoztunk meg, és amelyeket el szeretnénk menteni és használni szeretnénk a következő futtatások során. Ezeket az adatokat sqlite-ben írjuk.
Megjegyzéseket is hagyunk, és HTTP-visszahíváson keresztül módosítjuk a jegy állapotát.
HTTP visszahívás
# Make callback to Diskobot App
# Variables:
# callback_post_body: # A dict with follow keys. All keys are optional
# msg: If exist it would be posted to Jira as comment
# data: If exist it would be saved in Incident.variables
# desire_state: Set desire_state for incident
# status: If exist Proceed issue to that status
- name: Callback to Diskobot app (jira comment/status)
uri:
url: "{{ callback_url }}/{{ devname }}"
user: "{{ diskobot_user }}"
password: "{{ diskobot_pass }}"
force_basic_auth: True
method: POST
body: "{{ callback_post_body | to_json }}"
body_format: json
delegate_to: 127.0.0.1
Mint sok azonos típusú feladatot, ezt is egy külön közös fájlba helyezzük, és szükség esetén beépítjük, hogy ne ismétlődjön folyamatosan a játékkönyvekben. Ez magában foglalja a callback_ url-t, amely tartalmazza a probléma kulcsát és a gazdagép nevét. Amikor az Ansible végrehajtja ezt a POST-kérést, a bot megérti, hogy ez egy ilyen és ehhez hasonló incidens részeként érkezett.
És itt van egy példa a playbookból, amelyben egy MD-eszközről lemezt adunk ki:
# Save mdadm configuration
- include: common/callback.yml
vars:
callback_post_body:
status: 'Ready to change'
msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
data:
mdadm_data: "{{ mdadm_remove_disk.removed }}"
parted_info: "{{ parted_info | default() }}"
when:
- mdadm_remove_disk | changed
- mdadm_remove_disk.removed
Ez a feladat átviszi a Jira jegyet „Módosításra kész” állapotba, és megjegyzést fűz hozzá. Ezenkívül az mdam_data változó azon md eszközök listáját tárolja, amelyekről a lemezt eltávolították, a parted_info pedig egy partíció kiíratást tárol a partedből.
Amikor a mérnök behelyez egy új lemezt, ezekkel a változókkal visszaállíthatjuk a partíció kiíratását, valamint behelyezhetjük a lemezt azokhoz az md eszközökhöz, amelyekről eltávolították.
Lehetséges ellenőrzési mód
Ijesztő volt bekapcsolni az automatikát. Ezért úgy döntöttünk, hogy az összes játékkönyvet ebben a módban futtatjuk
, amelyben az Ansible nem hajt végre semmilyen műveletet a szervereken, csak emulálja azokat.
Az ilyen indítás egy külön visszahívási modulon keresztül fut, és a játékkönyv végrehajtásának eredménye megjegyzésként mentődik a Jira-ba.
Először is, ez lehetővé tette a bot és a játékkönyvek működésének érvényesítését. Másodszor, növelte a rendszergazdák bizalmát a botban.
Amikor átmentünk az ellenőrzésen, és rájöttünk, hogy az Ansible-t nem csak száraz futási módban lehet futtatni, létrehoztunk egy Futtatás Diskobot gombot a Jira-ban, hogy ugyanazt a játékkönyvet ugyanazon a változókkal indítsuk el ugyanazon a gazdagépen, de normál módban.
Ezenkívül a gomb a játékkönyv újraindítására szolgál, ha összeomlik.
Playbooks szerkezet
Már említettem, hogy a Jira jegy állapotától függően a bot különböző játékkönyveket indít el.
Először is, sokkal könnyebb megszervezni a bejáratot.
Másodszor, bizonyos esetekben egyszerűen szükséges.
Például egy rendszerlemez cseréjekor először el kell menni a telepítési rendszerre, létre kell hozni egy feladatot, és a megfelelő telepítés után a szerver elérhetővé válik ssh-n keresztül, és ráteheti az alkalmazást. Ha mindezt egy játékkönyvben tennénk, akkor az Ansible nem tudná befejezni, mert a házigazda nem elérhető.
Minden kiszolgálócsoporthoz Ansible szerepkört használunk. Itt láthatja, hogyan vannak elrendezve a játékfüzet(ek) az egyikben.
Ez azért kényelmes, mert azonnal látható, hogy mely feladatok hol találhatók. A main.yml-ben, amely az Ansible szerep bemenete, egyszerűen csak jegy státusz vagy általános, mindenki számára szükséges feladatok szerepelhetnek, például azonosítás átadása vagy token fogadása.
nyomozás.yml
Vizsgálat és Nyitott állapotú jegyekre fut. A legfontosabb dolog ennél a forgatókönyvnél a blokkeszköz neve. Ez az információ nem mindig áll rendelkezésre.
Megszerzéséhez elemezzük a Jira összegzést, a Zabbix trigger utolsó értékét. Tartalmazhatja a blokkeszköz nevét – szerencsés. Vagy tartalmazhat egy csatolási pontot, akkor el kell menni a szerverre, elemezni és ki kell számítani a szükséges lemezt. A trigger scsi címet vagy más információt is továbbíthat. De az is előfordul, hogy nincs nyom, és elemezni kell.
Miután megtudtuk a blokkeszköz nevét, információkat gyűjtünk róla a lemez típusáról és méretéről, hogy kitöltsük a Jira mezőit. Eltávolítjuk a gyártóra, modellre, firmware-re, azonosítóra, SMART-ra vonatkozó információkat is, és mindezt egy megjegyzésbe illesztjük a Jira jegybe. A rendszergazdának és a mérnöknek többé nem kell keresnie ezeket az adatokat. 🙂
prepar2change.yml
A lemez eltávolítása a forgásból, előkészítés a cserére. A legnehezebb és legfontosabb szakasz. Itt állíthatja le az alkalmazást, amikor nem szabad leállítani. Vagy vegyen ki egy lemezt, amelyen nem volt elegendő replika, és ezáltal hatással van a felhasználókra, és elveszít néhány adatot. Itt van a legtöbb ellenőrzés és értesítés a chatben.
A legegyszerűbb esetben egy lemez eltávolításáról beszélünk egy HW/MD RAID-ről.
Bonyolultabb helyzetekben (tárolórendszereinkben), amikor a mentés alkalmazás szinten történik, az API-n keresztül az alkalmazáshoz kell menni, jelenteni kell a lemezkimenetet, deaktiválni és elindítani a helyreállítást.
Most tömegesen vándorolunk ide , és ha a szerver felhő alapú, akkor a Diskobot meghívja a felhő API-t, és azt mondja, hogy ezzel a minionnal fog működni – a konténereket futtató szerverrel –, és megkérdezi, hogy „minden konténer áttelepítése erről a minionról”. És egyúttal bekapcsolja a lemez háttérvilágítását, hogy a mérnök azonnal láthassa, melyiket kell kihúzni.
megváltozott.yml
A lemez cseréje után először ellenőrizzük annak elérhetőségét.
A mérnökök nem mindig telepítenek új meghajtókat, ezért hozzáadtuk a számunkra megfelelő SMART értékek ellenőrzését.
Milyen tulajdonságokat nézünk?Átcsoportosított szektorok száma (5) < 100
Jelenlegi függőben lévő szektorok száma (107) == 0
Ha a hajtás nem felel meg a teszten, a mérnök értesítést kap, hogy cserélje ki újra. Ha minden rendben van, a háttérvilágítás kikapcsol, a jelölések megjelennek és a lemez forog.
kész.yml
A legegyszerűbb eset: HW/SW raid szinkronizálás ellenőrzése vagy adatszinkronizálás befejezése az alkalmazásban.
Alkalmazás API
Többször említettem, hogy a bot gyakran hozzáfér az alkalmazás API-khoz. Természetesen nem minden alkalmazás rendelkezett a szükséges módszerekkel, ezért módosítani kellett. Íme az általunk használt legfontosabb módszerek:
- Állapot. A fürt vagy lemez állapota annak megértéséhez, hogy lehet-e vele dolgozni;
- Indítás/leállítás. Lemez aktiválása/deaktiválása;
- Migráció/visszaállítás. Adatmigráció és helyreállítás csere közben és után.
Az Ansible tanulságai
Nagyon szeretem Ansible-t. De gyakran, amikor különböző nyílt forráskódú projekteket nézek, és látom, hogyan írnak az emberek játékkönyveket, egy kicsit megijedek. A mikor/hurok összetett logikai összefonódásai, a rugalmasság és az idempotencia hiánya a shell/parancs gyakori használata miatt.
Úgy döntöttünk, hogy mindent leegyszerűsítünk, amennyire csak lehetséges, kihasználva az Ansible előnyeit - a modularitást. A legmagasabb szinten vannak a játékkönyvek, amelyeket bármely rendszergazda, külső fejlesztő írhat, aki egy kicsit ismeri az Ansible-t.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Ha valamilyen logikát nehéz megvalósítani a játékkönyvekben, áthelyezzük egy Ansible modulba vagy szűrőbe. A szkriptek Pythonban vagy bármely más nyelven írhatók.
Könnyen és gyorsan írhatók. Például a lemez háttérvilágítási modulja, amelyre a fenti példa látható, 265 sorból áll.
A legalsó szinten a könyvtár található. Ehhez a projekthez külön alkalmazást írtunk, egyfajta absztrakciót a megfelelő kéréseket végrehajtó hardveres és szoftveres RAID-ek felett.
Az Ansible legnagyobb erőssége az egyszerűség és az áttekinthető játékkönyvek. Úgy gondolom, hogy ezt kell használnia, és nem kell ijesztő yaml fájlokat generálnia, és rengeteg feltételt, shell kódot és ciklusokat kell létrehoznia.
Ha meg szeretné ismételni az Ansible API-val kapcsolatos tapasztalatainkat, két dolgot tartson szem előtt:
- A Playbook_executor és a játékkönyvek általában nem kaphatnak időtúllépést. Időtúllépés van az ssh munkamenetben, de nincs időkorlát a játékkönyvben. Ha olyan lemezt próbálunk lecsatolni, amely már nem létezik a rendszerben, a playbook a végtelenségig futni fog, így az elindítását külön wrapperbe kellett csomagolnunk, és időtúllépéssel meg kellett ölnünk.
- Az Ansible forked folyamatokon fut, ezért az API nem szálbiztos. Minden játékkönyvünket egyszálon futtatjuk.
Ennek eredményeként a lemezek mintegy 80%-ának cseréjét automatizálni tudtuk. Összességében a cserearány megduplázódott. Ma az adminisztrátor csak megnézi az incidenst, és eldönti, hogy kell-e cserélni a lemezt vagy sem, majd kattint egyet.
De most kezdünk egy újabb problémába ütközni: néhány új rendszergazda nem tudja, hogyan kell meghajtót cserélni. 🙂
Forrás: will.com