Failover: meid nuhtleb perfektsionism ja... laiskus

Suvel väheneb tavaliselt nii ostjate aktiivsus kui ka veebiprojektide infrastruktuuri muudatuste intensiivsus, ütleb meile Kapten Ilmselge. Lihtsalt sellepärast, et isegi IT- spetsialistid, juhtub, käivad puhkamas. Ja CTO ka. Mida raskem on neile, kes jäävad ametisse, aga praegu ei ole sellest juttu: võib-olla on just sellepärast suvi - parim aeg, et rahulikult mõelda olemasolevale broneerimise skeemile ja koostada plaan selle parendamiseks. Ja selles osas on teile kasulik Einar Andrejevi kogemus AdminDivision, millest ta rääkis konverentsil Uptime day.

Backup-platvormide loomisel ja broneerimisel on mitmeid lõkse, millesse võib sattuda. Ja nendesse sattuda ei tohi. Meid hukutab kõikjal selles, nagu ka paljus muus, perfektsionism ja… laiskus. Püüame teha kõike täiesti täiuslikult, kuigi täiuslikult ei pea! Tuleb teha ainult teatud asju, aga teha need õigesti, lõpuni viia, et need korralikult töötaksid.

Failover ei ole mingi lõbus mänguasi, mis on lihtsalt olemas; see on asi, mis peab saavutama ühe eesmärgi — vähendada seisakuaega, et teenus ja ettevõte kaotaks vähem raha. Kõikide varukoopiametodite puhul soovitan mõelda järgmistel ridadel: kus on raha?

Esimene lõks: kui me ehitame suurt ja usaldusväärset süsteemi ning tegeleme varukoopiate tegemisega — vähendame õnnetuste arvu. See on kohutav eksitus. Varukoopia tegemisega suurendame tõenäoliselt õnnetuste arvu. Kui teeme kõik õigesti, vähendame kombineeritult seisakuaega. Õnnetusi tuleb rohkem, kuid need toimuvad väiksemate kuludega. Mis on varukoopia tegemine? — see on süsteemi keerukuse suurendamine. Iga keerukus on halb: meil on rohkem kruve, rohkem hammasrattasid, kokku rohkem komponente — seega on rike tõenäolisem. Ja nad murduvad tõepoolest. Ja nad murduvad sagedamini. Näiteks: ütleme, et meil on mingi veebileht PHP ja MySQL abil. Ja see tuleb kiiresti varundada.

Noh, võtame teise platvormi, loome identse süsteemi... keerukus kahekordistub — meil on kaks üksust. Ja lisaks rakendame me teatud andmete ülekande loogikat ühelt platvormilt teisele — see tähendab andmete replikatsiooni, staatika kopeerimist ja nii edasi. Noh, replikatsiooni loogika on tavaliselt väga keeruline, mistõttu süsteemi kogune keerukus võib olla mitte 2, vaid 3, 5, 10 korda suurem.

Teine lõks: kui me ehitame tõeliselt suuri ja keerulisi süsteeme, fantaseerime, mida me lõppkokkuvõttes soovime. Voilà: me tahame superusaldusväärset süsteemi, mis töötab täiesti katkestusteta, lülitub üle poole sekundi (veel parem, kui kohe), ja hakkame oma unistusi ellu viima. Kuid siin on üks nüanss: mida vähem soovitud ümberlülitusaeg on, seda keerulisemaks muutub süsteemi loogika. Mida keerukamaks me peame seda loogikat tegema, seda sagedamini süsteem rikki läheb. Ja võib juhtuda, et satume väga ebameeldivasse olukorda: me püüame iga hinna eest katkestusaega vähendada, aga tegelikult teeme kõik keerukamaks, ja kui midagi läheb valesti, on katkestusaeg lõppkokkuvõttes suurem. Tihti tabad ennast mõttelt: oh… oleks parem, kui me ei oleks varunud. Oluliselt parem oleks, kui see üksnes töötaks ja oleks arusaadav katkestusaeg.

Kuidas sellise olukorraga võidelda? Tuleb lõpetada endale valetamist, lõpetada endale meelitamine, et me hakkame siin ehitama kosmoselaeva, vaid mõista adekvaatselt, kui kaua projekt võib seisma jääda. Ja selle maksimaalse aja alusel valime, milliseid meetodeid kasutame meie süsteemi usaldusväärsuse suurendamiseks.

Õige aeg «elust lugude» jaoks... muidugi elust.

Näide number üks

Kujutage ette visiitkaardisaidi torutootmisettevõttest nr 1 linnas N. Sellel on suured kirjad — TORUTOOTMISETTEVÕTE NR 1. Natuke allpool on loosung: «Meie torud on N linna kõige ümaramad torud». Ja all on peadirektori telefoninumber ja tema nimi. Mõistame, et broneerimine on vajalik — see on väga oluline asjaolu! Alustame uurimisega, millest see koosneb. HTML-staatika — see tähendab paar pilti, kus peadirektor koos oma partneriga arutavad mingit kokkulepet sauna lauas. Alustame mõtlema seiskamisaegadele. Tuleb meelde: seal peab olema viis minutit, mitte rohkem. Ja siis küsimus: kui palju on meie saidilt tulnud müüke? Kui palju-kui palju? Mis tähendab «null»? Ja see tähendab: sest kõik neli tehingut eelmisel aastal tegi peadirektor sama laua taga, nende samade inimestega, kellega nad saunas laua taga istuvad. Ja mõistame, et isegi kui päev veedetakse saidiga — pole midagi hullu.

Sissejuhatuse põhjal on selle loo tõstmiseks aega päev. Alustame broneerimissemma mõtlemist. Valime parima broneerimisplaane antud näite jaoks: me ei kasuta broneerimist. Kõik see tõuseb üles ühe administraatori poolt poole tunni jooksul, sealhulgas pauside jooksul. Paigaldada veebiserver, laadida failid — kõik. See hakkab tööle. Mingeid tähelepanusid ei ole vaja jälgida, millelegi ei ole vaja erilist tähelepanu pöörata. Seega on esimese näite järeldus üsna ilmne: teenuseid, mida ei ole vaja broneerida — ei ole vaja broneerida.

Teine näide

Ettevõtte blogi: spetsiaalselt koolitatud inimesed kirjutavad sinna uudiseid, näiteks osalesime sellises näitusel ja nüüd oleme välja lasknud uue toote ja nii edasi. Oletame, et see on tavaline PHP koos WordPressiga, väike andmebaas ja natuke staatilist sisu. Muidugi tuleb jälle meeldiv mõte, et kauem ei tohi kindlasti oodata — "mitte rohkem kui viis minutit!", kõik see. Aga mõelgem edasi. Mida see blogi teeb? Sinna tulevad külastajad Yandexist ja Google'ist mingite päringute kaudu, orgaaniliselt. Väga hea. Aga kas müük on kuidagi sellele seotud? Üks arusaam: mitte just palju. Reklaamiliiklus suundub peamisele veebisaidile, mis asub teisel serveril. Alustame mõtlemist broneeringu skeemile blogis. Hea oleks, kui selle paaritunni jooksul üles tõsta ja sellele oleks mõistlik ette valmistuda. Mõistlik on võtta teises andmekeskuses server, installida sellele keskkond, st veebiserver, PHP, WordPress, MySQL ja hoida see ooterežiimil. Hetkel, kui me mõistame, et kõik on katki, peame tegema kaks asja — taastama 50 MB suuruse MySQL dumpi, mis läheb seal nagu minutiga, ja taastama sinna mingi koguse pilte varukoopiast. See ei võta samuti kaua aega. Seega tõuseb kogu see asi poole tunni jooksul. Ei mingeid replikatsioone või halastas jumal, automaatset failover'it. Järeldus: see, mida me saame kiiresti varukoopiast taastada, pole broneerimise tegemiseks vajalik.

Näide number kolm, keerulisem

Veebipood. PhP koos natuke muudetud open heartiga, mysql tugevate andmetega. Üksjagu staatilist sisu (sest veebipoes on ilusad HD-pildid ja kõik selline), Redis sessioonide jaoks ja Elasticsearch otsingu jaoks. Hakkame mõtlema seisakuajale. Siin on selge, et päev ilma probleemideta veebipoe olla ei saa. Mida kauem see seisab, seda rohkem raha me kaotame. Peame kiirendama. Ja kui palju? Arvan, et kui me tunni jooksul seisame, ei juhtu kellegagi midagi. Jah, me kaotame midagi, kuid kui hakkame liiga pingutama - see ainult halvendab olukorda. Määratleme seiskamise skeemi, mis on tunni jooksul lubatud.

Kuidas kõik see broneerida? Masin on igal juhul vajalik: tund aega on üsna vähe. Mysql: siin on juba vajalik replikatsioon, elav replikatsioon, sest tunniga 100 GB dump'i tõenäoliselt ei mahuks. Statiika, pildid: taas, tunni jooksul võib 500 GB mitte sisse mahtuda. Seega on parem pildid kohe kopeerida. Redis: siin on huvitavam. Redis-asetsevad seansid — me ei saa seda lihtsalt ära hävitada. Sest see ei oleks just väga hea: kõik kasutajad jäävad välja logitud, ostukorvid jäävad tühjaks ja nii edasi. Inimesed peavad uuesti oma login'i ja paroolid sisestama ning palju inimesi võib lahkuda ja ostu lõpetada. Taas, konversioon langeb. Teiselt poolt, Redis on täpselt sama aktiivne, viimane sisseloginud kasutajatega, ega ka see ei ole vajalik. Hea kompromiss on võtta Redis ja taastada see varukoopiatest, eilsest, või kui teil on see iga tunni pärast olemas, siis tunni vanusest. Õnneks on selle taastamine varukoopiast ühe faili kopeerimine. Ja kõige huvitavam lugu on Elasticsearch. Kes on kunagi käivitanud MySQL replikatsiooni? Kes on kunagi käivitanud Elasticsearch replikatsiooni? Ja kelle replikatsioon töötas pärast tavaliselt normaalselt? Mida ma silmas pean: me näeme meie süsteemis mingit olemust. See näib olevat kasulik, kuid siiski keeruline.
Kompleksne, kuna meie inseneridel pole selle kasutamise kogemust. Või on olemas negatiivsed kogemused. Olles teadlikud, et see on endiselt üsna uus tehnoloogia, millega kaasnevad teatud nüansid ja toimetulekud. Mõtleme… Mis siis nüüd, elastic on samuti üsna mahukas, ka selle taastamine võtab aega, mida teha? Saame aru, et elasticit kasutatakse meie puhul otsimiseks. Kuidas meie e-pood siis müüb? Kõnnime turundajate juurde, küsime, kust inimesed tulevad. Nad vastavad: "90% tulevad Yandexi turult otse toote lehele." Ja kas ostavad või mitte. Seetõttu vajab 10% kasutajatest otsingut. Ja elastic'i replikatsiooni hoidmine, eriti erinevate andmekeskuste vahel erinevates tsoonides, - seal on tõesti palju nüansse. Mis on lahendus? Võtame elastic'i reserveeritud platvormil ja ei tee sellega midagi. Kui protsess venib, siis võib-olla tõstame selle kunagi, kuid see pole kindel. Üldiselt jääb järeldus enam-vähem samaks: teenuseid, millel pole rahalisi tagajärgi, me ei reserveeri. Et skeem püsiks lihtsamana.

Näide number neli, veel keerulisem

Integratsioon: lillede müük, taksoteenuse väljakutse, kaupade müük – sisuliselt ükskõik, mida. Tõsine asi, mis töötab 24/7 suure kasutajate arvu juures. Täis huvitavat tehnoloogiat, kus on huvitavad andmebaasid, lahendused, suur koormus, ja mis kõige tähtsam, see ei saa olla nelja minuti jooksul välja lülitatud. Mitte ainult mitte selles osas, et inimesed ei osta, vaid sellepärast, et inimesed näevad, et see ei tööta, tunnevad pettumust ja võivad üldse mitte tagasi tulla.

Olgu. Viis minutit. Mida me sellega teeme? Sellisel juhul ehitame tõsiselt, kogu raha eest, tegeliku varukoha koos kogu ja kõigega replikeerimisega, ja võib-olla isegi automatiseerime selle varukoha vahetamise maksimaalselt. Ja lisaks ei tohi unustada teha ühte olulist asja: kirjutada ümberlülitamise eeskiri. Eeskiri, isegi kui teil on kõik automaatne, võib olla väga lihtne. Näiteks: "käivitada selline ansible'i stsenaarium", "route 53-s vajuta sellele rukile" jne – kuid see peab olema mingi täpne tegevuste loetelu.

Ja, see on arusaadav. Replikatsiooni vahetamine on triviaalne ülesanne, või siis vahetub see iseenesest. Domeeninime muutmine DNS-is on sama lihtne. Probleem on aga selles, et kui selline projekt kokku kukub, algab paanika, ja isegi kõige tugevamad, kogenud adminnid võivad selle ees nõrkena tunduda. Ilma selgete juhisteta "ava terminal, mine siia, meie serveri aadress on endiselt see" on raske ülesande viie minuti jooksul ellu viia. Lisaks, kui me seda regulatsiooni järgime, on lihtne fikseerida igasuguseid muudatusi infrastruktuuris, näiteks – ja vastavalt regulatsiooni muuta.
Aga kui varundussüsteem on väga keeruline ja mingil hetkel teeme vea, siis võime ka meie varukoha maapinda jätta, ning lisaks muuta andmed mõlemal platvormil kõikeks, see oleks väga kurb.

Näide number viis, täielik hardcore

Rahvusvaheline teenus, mis omab sadu miljoneid kasutajaid üle kogu maailma. Kõik ajavööndid, mis vaid olemas, kõrge koormusega, ei tohi mingil juhul välja kukkuda. Üks minut — ja juba on kurb. Mida teha? Reserveerige, uuesti täieliku programmiga. Oleme teinud kõik, millest rääkis eelnevas näites, ja isegi natuke rohkem. Täiuslik maailm ja meie infrastruktuur — see on kõik IaaC DevOps mõistes. See tähendab, et kõik on git'is, ja vajutage lihtsalt nuppu.

Mida puudu jääb? Ühte — harjutustest. Ilma nendeta ei saa. Tundub, et meil on kõik ideaalne, meil on kõik täiesti kontrolli all. Vajutame nuppu, kõik toimub. Isegi kui see nii on — ja me mõistame, et nii ei juhtu — meie süsteem suhtleb mõne muu süsteemiga. Näiteks DNS Route 53-lt, S3 salvestusruum, integratsioon erinevate API-dega. Me ei suuda kõike ette näha selles hüpoteetilises eksperimendis. Ja seni, kuni me tõesti lülitit ei lükka — ei saa me teada, kas see töötab või mitte.

Küllap see ongi kõik. Ärge laiskuge ja ärge liialdage. Ja olgu uptime teiega!

Allikas: habr.com