Yn 'e simmer, sawol de oankeap aktiviteit en de yntinsiteit fan feroarings yn de ynfrastruktuer fan web projekten tradisjoneel ôfnimme, Captain Obvious fertelt ús. Gewoan omdat sels IT-spesjalisten soms op fakânsje geane. En ek CTO. It is des te dreger foar dyjingen dy't yn it amt bliuwe, mar dêr giet it no net om: miskien is de simmer dêrom de bêste perioade om stadich nei te tinken oer de besteande reservearringsregeling en in plan op te stellen om dy te ferbetterjen. En de ûnderfining fan Yegor Andreev út , dêr't er oer spruts op 'e konferinsje .
D'r binne ferskate falkûlen wêryn jo kinne falle by it bouwen fan backup-siden. En it is perfoarst ûnmooglik om te fongen yn harren. En wat ús yn dit alles ferneatiget, lykas yn in protte oare dingen, is perfeksjonisme en ... loaiens. Wy besykje alles te dwaan, alles, alles perfekt, mar wy hoege it net perfekt te dwaan! Jo moatte allinich bepaalde dingen dwaan, mar dogge se goed, foltôgje se sadat se goed wurkje.
Failover is net in soarte fan leuk leuk ding "sa wêze it"; dit is in ding dat krekt ien ding moat dwaan - downtime ferminderje sadat de tsjinst, it bedriuw, minder jild ferliest. En yn alle reservearring metoaden, Ik stel te tinken yn de folgjende kontekst: wêr is it jild?
Earste trap: as wy grutte, betroubere systemen bouwe en oerstallich meitsje, ferminderje wy it oantal ûngelokken. Dit is in skriklike misfetting. As wy meidwaan oan ûntslach, sille wy wierskynlik it oantal ûngelokken ferheegje. En as wy alles goed dogge, dan sille wy kollektyf downtime ferminderje. Der komme mear ûngemakken, mar dy komme tsjin legere kosten. Wat is in reservearring? - dit is in komplikaasje fan it systeem. Elke komplikaasje is min: wy hawwe mear tandwielen, mear gears, yn ien wurd, mear eleminten - en dus in hegere kâns op ôfbraak. En se sille echt brekke. En se sille faker brekke. In ienfâldich foarbyld: lit ús sizze dat wy in webside hawwe mei PHP en MySQL. En it moat driuwend reservearre wurde.
Shtosh (c) Wy nimme de twadde side, bouwe in identike systeem ... De kompleksiteit wurdt twa kear sa grut - wy hawwe twa entiteiten. Wy rôlje ek in bepaalde logika út foar it oerdragen fan gegevens fan de iene side nei de oare - dat is, gegevensreplikaasje, kopiearjen fan statyske gegevens, ensfh. Dat, de replikaasjelogika is normaal heul kompleks, en dêrom kin de totale kompleksiteit fan it systeem net 2, mar 3, 5, 10 kear grutter wêze.
Twadde trap: as wy echt grutte komplekse systemen bouwe, fantasearje wy oer wat wy op it lêst wolle krije. Voila: wy wolle in superbetrouber systeem krije dat wurket sûnder downtime, skeakelt yn in heale sekonde (of noch better, direkt), en wy begjinne dreamen wier te meitsjen. Mar hjir is ek in nuânse: hoe koarter de winske skeakeltiid, hoe komplekser de systeemlogika wurdt. De komplekser wy moatte meitsje dizze logika, hoe faker it systeem sil ôfbrekke. En jo kinne yn in heul onaangename situaasje telâne komme: wy besykje mei alle macht om downtime te ferminderjen, mar feitlik meitsje wy alles yngewikkelder, en as der wat mis giet, sil de downtime úteinlik langer wurde. Hjir falt je faaks te tinken: no... it soe better wêze om net te reservearjen. It soe better wêze as it allinich wurke en mei begryplike downtime.
Hoe kinne jo dit bestride? Wy moatte ophâlde mei te lizzen tsjin ússels, ophâlde ússels te fladderjen dat wy hjir no in romteskip bouwe sille, mar adekwaat begripe hoe lang it projekt lizze kin. En foar dizze maksimale tiid sille wy kieze hokker metoaden wy eins sille brûke om de betrouberens fan ús systeem te fergrutsjen.
It wurdt tiid foar “ferhalen út w”... út it libben fansels.
Foarbyld nûmer ien
Stel jo in webside foar visitekaarten foar foar Pipe Rolling Plant No. 1 yn 'e stêd N. It stiet yn grutte letters - PIPE ROLLING PLANT No. Krekt ûnder is de slogan: "Us pipen binne de rûnste pipen yn N." En hjirûnder is it tillefoannûmer fan 'e CEO en syn namme. Wy begripe dat jo in reservearje moatte meitsje - dit is in heul wichtich ding! Litte wy begjinne út te finen wêrút it bestiet. Html-statyk - dat is, in pear foto's dêr't de algemien direkteur, yn feite, besprekt in soarte fan folgjende deal oan 'e tafel yn it badhûs mei syn partner. Wy begjinne te tinken oer downtime. It komt yn 't sin: dêr moatte jo fiif minuten lizze, net mear. En dan komt de fraach: hoefolle ferkeapen wiene der yn it algemien fan dizze side fan ús? Hoefolle - hoefolle? Wat betsjut "nul"? En dat betsjut: want de generaal die ferline jier alle fjouwer transaksjes oan deselde tafel, mei deselde minsken dêr't se mei nei it badhûs gean en oan tafel sitte. En wy begripe dat sels as de side foar in dei sit, neat ferskrikliks sil barre.
Op grûn fan de ynliedende ynformaasje is der in dei om dit ferhaal op te heljen. Litte wy begjinne te tinken oer in ûntslachskema. En wy kieze it meast ideale ûntslachskema foar dit foarbyld: wy brûke gjin ûntslach. Dit hiele ding kin troch elke admin yn in heal oere opheft wurde mei reekpauzes. Ynstallearje in webtsjinner, foegje bestannen ta - dat is it. It sil wurkje. Jo hoege neat yn 'e gaten te hâlden, jo hoege neat spesjaal omtinken te jaan. Dat is, de konklúzje út foarbyld nûmer ien is frij dúdlik: tsjinsten dy't net reservearre wurde hoege net reservearre te wurden.
Foarbyld nûmer twa
Bedriuwsblog: spesjaal oplate minsken skriuwe dêr nijs, wy hawwe meidien oan sa'n en sa'n útstalling, mar wy hawwe noch in nij produkt útbrocht, ensfh. Litte wy sizze dat dit standert PHP is mei WordPress, in lytse database en in bytsje statysk. Fansels komt it wer yn 't sin dat jo ûnder gjin omstannichheden lizze moatte - "net mear as fiif minuten!" Dat is alles. Mar litte wy fierder tinke. Wat docht dit blog? Minsken komme dêr fan Yandex, fan Google basearre op guon fragen, organysk. Grut. Hat ferkeap der wat mei te krijen? Epifany: net echt. Reklameferkear giet nei de haadside, dy't op in oare masine is. Litte wy begjinne te tinken oer in boekingsskema. Op in goede manier moat it yn in pear oeren opheft wurde, en it soe moai wêze om hjirop ta te rieden. It soe ridlik wêze om in masine fan in oar datasintrum te nimmen, de omjouwing derop te rôljen, dat is in webserver, PHP, WordPress, MySQL, en it dêr te litten. Op it momint dat wy begripe dat alles is brutsen, moatte wy twa dingen dwaan - rôlje de mysql-dump 50 meter út, it sil der yn in minút fleane, en rôlje dêr in bepaald oantal foto's út fan 'e reservekopy. Dit is der ek net foar God wit hoe lang. Sa komt yn in healoere it gehiel omheech. Gjin replikaasje, of God ferjou my, automatyske failover. Konklúzje: wat wy fluch kinne útrolje út in reservekopy hoecht gjin reservekopy te wurden.
Foarbyld nûmer trije, yngewikkelder
Online winkel. PhP mei iepen hert is in bytsje tweaked, mysql mei in solide basis. Hiel wat statyske (de online winkel hat ommers prachtige HD-ôfbyldings en al dat guod), Redis foar de sesje en Elasticsearch foar sykjen. Wy begjinne te tinken oer downtime. En hjir is fansels fanselssprekkend dat in online winkel net in dei pynlik lizze kin. Na, hoe langer it leit, hoe mear jild wy ferlieze. It is it wurdich om te fersnellen. Hoefolle? Ik tink dat as wy in oere lizze, sil gjinien gek wurde. Ja, wy sille wat ferlieze, mar as wy hurd begjinne te wurkjen, wurdt it allinnich mar slimmer. Wy definiearje in skema fan downtime tastien per oere.
Hoe kin dit alles reservearre wurde? Jo hawwe yn alle gefallen in auto nedich: in oere tiid is frij min. Mysql: hjir hawwe wy al replikaasje nedich, live replikaasje, want yn in oere sil 100 GB nei alle gedachten net tafoege wurde oan 'e dump. Statics, pictures: wer, yn in oere 500 GB meie gjin tiid om te wurde tafoege. Dêrom is it better om de foto's direkt te kopiearjen. Redis: dit is wêr't dingen ynteressant wurde. Yn Redis wurde sesjes opslein - wy kinne it net gewoan nimme en begrave. Want dit sil net hiel goed wêze: alle brûkers wurde ôfmeld, har koerkes wurde leech, ensfh. Minsken sille wurde twongen om opnij ynfiere harren brûkersnamme en wachtwurd, en in protte minsken meie ôfbrekke en net foltôgje de oankeap. Nochris sille konversaasjes sakje. Oan 'e oare kant is Redis direkt aktueel, mei de lêste oanmelde brûkers wierskynlik ek net nedich. En in goed kompromis is Redis te nimmen en it te herstellen fan in reservekopy fan juster, of, as jo it elke oere dogge, fan in oere lyn. Gelokkich betsjut it weromsette fan in reservekopy ien bestân kopiearje. En it meast nijsgjirrige ferhaal is Elasticsearch. Wa hat oait MySQL-replikaasje opnommen? Wa hat ea Elasticsearch-replikaasje ophelle? En foar wa wurke it normaal na? Wat ik bedoel is dat wy in bepaalde entiteit yn ús systeem sjogge. It liket nuttich te wêzen - mar it is kompleks.
Kompleks yn 'e sin dat ús kollega-yngenieurs gjin ûnderfining hawwe mei it wurkjen mei. Of der is in negative ûnderfining. Of wy begripe dat dit noch in frij nije technology is mei nuânses of rauheid. Wy tinke... Ferdomd, elastysk is ek sûn, it duorret ek lang om it fan in reservekopy te herstellen, wat moat ik dwaan? Wy begripe dat elastyk yn ús gefal wurdt brûkt foar sykjen. Hoe ferkeapet ús online winkel? Wy geane nei marketeers en freegje wêr't minsken wei komme. Se antwurdzje: "90% fan Yandex Market komt direkt nei de produktkaart." En of se keapje it of se dogge it net. Dêrom is sykjen nedich troch 10% fan brûkers. En it hâlden fan elastyske replikaasje, benammen tusken ferskate datasintra yn ferskate sônes, hat echt in protte nuânses. Hokker útgong? Wy nimme elastyk fan in reservearre side en dogge der neat mei. As de saak langer slûpt, sille wy it nei alle gedachten ienris ophelje, mar dit is net wis. Eins, de konklúzje is itselde, plus of minus: wy, wer, net reservearje tsjinsten dy't gjin ynfloed op jild. Om it diagram ienfâldiger te hâlden.
Foarbyld nûmer fjouwer, noch dreger
Integrator: blommen ferkeapje, in taksy skilje, guod ferkeapje, yn 't algemien, alles. In serieus ding dat 24/7 wurket foar in grut oantal brûkers. Mei in folweardige nijsgjirrige stack, wêr't ynteressante basis, oplossingen, hege lading binne, en it wichtichste, it docht sear om mear as 5 minuten te lizzen. Net allinich en net sa folle om't minsken net keapje, mar om't minsken sille sjen dat dit ding net wurket, sille se oerstjoer wurde en kinne hielendal net weromkomme.
OK. Fiif minuten. Wat sille wy hjirmei dwaan? Yn dit gefal brûke wy, lykas folwoeksenen, al it jild om in echte reservekopyside te bouwen, mei replikaasje fan alles, en miskien sels it wikseljen nei dizze side safolle mooglik automatisearje. En neist dit moatte jo ûnthâlde om ien wichtich ding te dwaan: eins de wikselregels skriuwe. De regeljouwing, sels as jo alles automatisearre hawwe, kinne heul ienfâldich wêze. Ut de searje "fiere sa'n en sa'n ansible skript", "klikke op sa'n en sa'n karfakje yn rûte 53" ensafuorthinne - mar dit moat in soarte fan krekte list fan aksjes wêze.
En alles liket dúdlik. It wikseljen fan replikaasje is in triviale taak, of it sil sels wikselje. It oerskriuwen fan in domeinnamme yn DNS is fan deselde searje. It probleem is dat as sa'n projekt mislearret, panyk begjint, en sels de sterkste, bebaarde admins kinne der gefoelich foar wêze. Sûnder dúdlike ynstruksjes "iepenje de terminal, kom hjir, it adres fan ús server is noch altyd sa," it is lestich om te foldwaan oan de 5-minuten tiidlimyt tawiisd foar reanimaasje. No, plus, as wy dizze regeljouwing brûke, is it maklik om bygelyks guon feroaringen yn 'e ynfrastruktuer op te nimmen en de regeljouwing neffens te feroarjen.
No, as it reservearringssysteem tige kompleks is en op in stuit hawwe wy in flater makke, dan kinne wy ús reservekopyside ferneatigje, en boppedat de gegevens yn in pompoen op beide siden feroarje - dit sil folslein tryst wêze.
Foarbyld nûmer fiif, folsleine hardcore
In ynternasjonale tsjinst mei hûnderten miljoenen brûkers oer de hiele wrâld. Alle tiidsônes der binne, hege lading op maksimum snelheid, do kinst net lizzen op alles. In minút - en it sil spitich wêze. Wat te dwaan? Reservearje, wer, neffens it folsleine programma. Wy diene alles wat ik praat oer yn it foarige foarbyld, en in bytsje mear. In ideale wrâld, en ús ynfrastruktuer is neffens alle begripen fan IaaC devops. Dat is, alles is yn git, en jo drukke gewoan op de knop.
Wat mist der? Ien - oefeningen. It is ûnmooglik sûnder harren. It liket derop dat alles perfekt is by ús, wy hawwe oer it algemien alles ûnder kontrôle. Wy drukke op de knop, alles bart. Sels as dit sa is - en wy begripe dat it net sa bart - ús systeem ynteraksje mei guon oare systemen. Bygelyks, dit is dns fan rûte 53, s3 opslach, yntegraasje mei guon api. Wy sille yn dit spekulative eksperimint net alles kinne foarsizze. En oant wy eins de skeakel lûke, sille wy net witte oft it sil wurkje of net.
Dat is wierskynlik alles. Wês net lui of oerdriuw it. En meie uptime wêze mei dy!
Boarne: www.habr.com