En la somero, kaj aĉeta aktiveco kaj la intenseco de ŝanĝoj en la infrastrukturo de retprojektoj tradicie malpliiĝas, Captain Obvious rakontas al ni. Simple ĉar eĉ IT-specialistoj foje ferias. Kaj ankaŭ CTO. Des pli malfacilas por tiuj, kiuj restas en la oficejo, sed tio ne estas la afero nun: eble tial somero estas la plej bona periodo por malrapide pensi pri la ekzistanta rezervadskemo kaj ellabori planon por plibonigi ĝin. Kaj la sperto de Jegor Andreev de , pri kiu li parolis en la konferenco .
Estas pluraj malfacilaĵoj, en kiuj vi povas fali dum konstruado de rezervaj retejoj. Kaj estas absolute neeble kaptiĝi en ili. Kaj kio ruinigas nin en ĉio ĉi, kiel en multaj aliaj aferoj, estas perfektismo kaj... maldiligento. Ni provas fari ĉion, ĉion, ĉion perfekte, sed ni ne bezonas fari ĝin perfekte! Vi nur bezonas fari iujn aferojn, sed fari ilin ĝuste, kompletigi ilin por ke ili funkciu ĝuste.
Malsukceso ne estas ia amuza, amuza afero; ĉi tio estas afero, kiu devus fari ĝuste unu aferon - redukti malfunkcion por ke la servo, la kompanio, perdu malpli da mono. Kaj en ĉiuj rezervmetodoj, mi sugestas pensi en la sekva kunteksto: kie estas la mono?
Unua kaptilo: kiam ni konstruas grandajn, fidindajn sistemojn kaj okupiĝas pri redundo, ni reduktas la nombron da akcidentoj. Ĉi tio estas terura miskompreniĝo. Kiam ni okupiĝas pri redundo, ni verŝajne pliigos la nombron da akcidentoj. Kaj se ni faras ĉion ĝuste, tiam kolektive ni reduktos malfunkcion. Estos pli da akcidentoj, sed ili okazos je pli malaltaj kostoj. Kio estas rezervado? - ĉi tio estas komplikaĵo de la sistemo. Ajna komplikaĵo estas malbona: ni havas pli da dentaĵoj, pli da dentaĵoj, unuvorte, pli da elementoj - kaj do pli altan ŝancon de paneo. Kaj ili vere rompiĝos. Kaj ili rompiĝos pli ofte. Simpla ekzemplo: ni diru, ke ni havas retejon kun PHP kaj MySQL. Kaj ĝi urĝe devas esti rezervita.
Shtosh (c) Ni prenas la duan retejon, konstruas identan sistemon... La komplekseco fariĝas duoble pli granda - ni havas du entojn. Ni ankaŭ disvolvas certan logikon por transdoni datumojn de unu retejo al alia - tio estas, kopiado de datumoj, kopiado de senmovaj datumoj ktp. Do, la replika logiko estas kutime tre kompleksa, kaj tial la totala komplekseco de la sistemo povas esti ne 2, sed 3, 5, 10 fojojn pli granda.
Dua kaptilo: kiam ni konstruas vere grandajn kompleksajn sistemojn, ni fantazias pri tio, kion ni volas atingi finfine. Voila: ni volas akiri super-fidindan sistemon, kiu funkcias sen ajna malfunkcio, ŝaltas en duona sekundo (aŭ pli bone, tuj), kaj ni komencas realigi revojn. Sed ĉi tie ankaŭ estas nuanco: ju pli mallonga estas la dezirata ŝanĝa tempo, des pli kompleksa fariĝas la sistema logiko. Ju pli kompleksa ni devas fari ĉi tiun logikon, des pli ofte la sistemo rompiĝos. Kaj vi povas finiĝi en tre malagrabla situacio: ni penas per ĉiuj niaj fortoj redukti malfunkciajn tempojn, sed fakte ni komplikas ĉion, kaj kiam io misfunkcias, malfunkciotempo finiĝos pli longa. Ĉi tie oni ofte kaptas vin pensante: nu... pli bone ne faru rezervon. Estus pli bone se ĝi funkcius sole kaj kun komprenebla malfunkcio.
Kiel vi povas batali ĉi tion? Ni devas ĉesi mensogi al ni mem, ĉesi flati nin, ke ni nun konstruos kosmoŝipon ĉi tie, sed adekvate kompreni kiom longe la projekto povas kuŝi. Kaj por ĉi tiu maksimuma tempo, ni elektos kiajn metodojn ni efektive uzos por pliigi la fidindecon de nia sistemo.
Estas tempo por “rakontoj el w”... el la vivo, kompreneble.
Ekzemplo numero unu
Imagu vizitkartan retejon por Pipe Rulanta Fabrikejo n-ro 1 en la urbo N. Ĝi diras per grandegaj literoj - TUBO RULANTUMINO N-ro 1. Ĝuste malsupre estas la slogano: "Niaj pipoj estas la plej rondaj pipoj en N." Kaj sube estas la telefonnumero de la CEO kaj lia nomo. Ni komprenas, ke vi devas fari rezervon - tio estas tre grava afero! Ni komencu eltrovi el kio ĝi konsistas. Html-statics - tio estas, kelkaj bildoj kie la ĝenerala direktoro, fakte, diskutas ian venontan interkonsenton ĉe la tablo en la banejo kun sia partnero. Ni komencas pensi pri malfunkcio. Ĝi venas al la menso: vi devas kuŝi tie kvin minutojn, ne pli. Kaj tiam ŝprucas la demando: kiom da vendoj estis de ĉi tiu nia retejo ĝenerale? Kiom-kiom? Kion signifas "nulo"? Kaj tio signifas: ĉar la generalo faris ĉiujn kvar transakciojn pasintjare ĉe la sama tablo, kun la samaj homoj kun kiuj ili iras al la banejo kaj sidas ĉe la tablo. Kaj ni komprenas, ke eĉ se la retejo sidas dum unu tago, nenio terura okazos.
Surbaze de la enkondukaj informoj, estas tago por levi ĉi tiun rakonton. Ni komencu pensi pri redunda skemo. Kaj ni elektas la plej idealan redundan skemon por ĉi tiu ekzemplo: ni ne uzas redundon. Ĉi tiu tuta afero povas esti levita de iu ajn administranto en duonhoro kun fumpaŭzoj. Instalu retservilon, aldonu dosierojn - jen ĝi. Ĝi funkcios. Vi ne bezonas observi ion ajn, vi ne bezonas aparte atenton al io ajn. Tio estas, la konkludo de ekzemplo numero unu estas sufiĉe evidenta: servoj kiuj ne bezonas esti rezervitaj ne bezonas esti rezervitaj.
Ekzemplo numero du
Firmaa blogo: speciale trejnitaj homoj verkas novaĵojn tie, ni partoprenis en tia kaj tia ekspozicio, sed ni publikigis alian novan produkton, ktp. Ni diru, ke ĉi tio estas norma PHP kun WordPress, malgranda datumbazo kaj iomete statika. Kompreneble, denove venas al la menso, ke vi ne devas kuŝi - "ne pli ol kvin minutojn!" Jen ĉio. Sed ni pripensu plu. Kion faras ĉi tiu blogo? Homoj venas tien de Yandex, de Guglo surbaze de iuj demandoj, organike. Bonege. Ĉu vendoj rilatas al ĝi? Epifanio: ne vere. Reklama trafiko iras al la ĉefa retejo, kiu estas sur malsama maŝino. Ni komencu pensi pri rezervoskemo. En bona maniero, ĝi devas esti levita post kelkaj horoj, kaj estus bone prepari por tio. Estus racie preni maŝinon de alia datumcentro, ruli la medion sur ĝin, tio estas, retservilo, PHP, WordPress, MySQL, kaj lasi ĝin tie. En la momento, kiam ni komprenas, ke ĉio estas rompita, ni devas fari du aferojn - elŝuti la mysql-ruĝejon 50 metrojn, ĝi flugos tien post minuto, kaj elŝutu certan nombron da bildoj de la sekurkopio tie. Ĉi tio ankaŭ ne estas tie ĉar Dio scias kiom longe. Tiel, en duonhoro la tuta afero leviĝas. Neniu reproduktado, aŭ Dio pardonu min, aŭtomata malsukceso. Konkludo: tio, kion ni povas rapide eligi el sekurkopio, ne bezonas subteni.
Ekzemplo numero tri, pli komplika
Reta vendejo. PhP kun malferma koro estas iom tajlita, mysql kun solida bazo. Sufiĉe multe da statika (finfine, la reta vendejo havas belajn HD-bildojn kaj ĉiujn tiajn aĵojn), Redis por la sesio kaj Elasticsearch por serĉo. Ni komencas pensi pri malfunkcio. Kaj ĉi tie, kompreneble, estas evidente, ke interreta vendejo ne povas kuŝi senpere dum unu tago. Post ĉio, ju pli longe ĝi kuŝas, des pli da mono ni perdas. Indas rapidigi. Kiom? Mi pensas, se ni kuŝos dum unu horo, neniu freneziĝos. Jes, ni perdos ion, sed se ni eklaboros, ĝi nur plimalboniĝos. Ni difinas skemon de malfunkcio permesita por horo.
Kiel ĉio ĉi povas esti rezervita? Oni ĉiukaze bezonas aŭton: horo da tempo estas sufiĉe malmulte. Mysql: ĉi tie ni jam bezonas reproduktadon, vivan reproduktadon, ĉar post unu horo 100 GB plej verŝajne ne estos aldonitaj al la rubejo. Statiko, bildoj: denove, post unu horo 500 GB eble ne havas tempon por esti aldonitaj. Tial, estas pli bone kopii la bildojn tuj. Redis: ĉi tie aferoj fariĝas interesaj. En Redis, sesioj estas konservitaj - ni ne povas simple preni ĝin kaj enterigi ĝin. Ĉar tio ne estos tre bona: ĉiuj uzantoj estos elsalutitaj, iliaj korboj estos malplenigitaj, ktp. Homoj estos devigitaj reenigi sian uzantnomon kaj pasvorton, kaj multaj homoj eble disiĝos kaj ne kompletigos la aĉeton. Denove, konvertiĝoj falos. Aliflanke, Redis estas rekte ĝisdatigita, kun la lastaj ensalutintaj uzantoj verŝajne ankaŭ ne bezonataj. Kaj bona kompromiso estas preni Redis kaj restarigi ĝin de sekurkopio de hieraŭ, aŭ, se vi faras ĝin ĉiuhore, de antaŭ unu horo. Feliĉe, restarigi ĝin de sekurkopio signifas kopii unu dosieron. Kaj la plej interesa rakonto estas Elasticsearch. Kiu iam prenis MySQL-reproduktadon? Kiu iam prenis reproduktadon de Elasticsearch? Kaj por kiu ĝi funkciis normale poste? Kion mi volas diri estas, ke ni vidas certan enton en nia sistemo. Ĝi ŝajnas esti utila - sed ĝi estas kompleksa.
Kompleksa en la senco, ke niaj kolegaj inĝenieroj ne havas sperton pri laboro. Aŭ estas negativa sperto. Aŭ ni komprenas, ke ĉi tio estas ankoraŭ sufiĉe nova teknologio kun nuancoj aŭ krudeco. Ni pensas... Damne, elasto ankaŭ estas sana, ankaŭ necesas longa tempo por restarigi ĝin de sekurkopio, kion mi faru? Ni komprenas, ke elasto en nia kazo estas uzata por serĉo. Kiel vendiĝas nia reta vendejo? Ni iras al merkatistoj kaj demandas de kie venas homoj. Ili respondas: "90% de Yandex Market venas rekte al la produktokarto." Kaj aŭ ili aĉetas ĝin aŭ ili ne. Tial serĉo bezonas 10% de uzantoj. Kaj konservi elastan reproduktadon, precipe inter malsamaj datumcentroj en malsamaj zonoj, vere havas multajn nuancojn. Kiu elirejo? Ni prenas elaston de rezervita retejo kaj faras nenion kun ĝi. Se la afero daŭras, ni verŝajne iam levos ĝin, sed tio ne estas certa. Efektive, la konkludo estas la sama, plus aŭ minus: ni, denove, ne rezervas servojn, kiuj ne influas monon. Por konservi la diagramon pli simpla.
Ekzemplo numero kvar, eĉ pli malfacila
Integratoro: vendado de floroj, vokado de taksio, vendado de varoj, ĝenerale, io ajn. Grava afero, kiu funkcias 24/7 por granda nombro da uzantoj. Kun plena interesa stako, kie estas interesaj bazoj, solvoj, alta ŝarĝo, kaj plej grave, doloras kuŝi dum pli ol 5 minutoj. Ne nur kaj ne tiom ĉar homoj ne aĉetos, sed ĉar homoj vidos, ke ĉi tiu afero ne funkcias, ili ĉagreniĝos kaj eble tute ne revenos.
BONE. Kvin minutoj. Kion ni faros pri ĉi tio? En ĉi tiu kazo, ni, kiel plenkreskuloj, uzas la tutan monon por konstrui veran rezervan retejon, kun reproduktado de ĉio, kaj eble eĉ aŭtomatigi ŝanĝadon al ĉi tiu retejo kiel eble plej multe. Kaj aldone al ĉi tio, vi devas memori fari unu gravan aferon: efektive, skribu la ŝanĝajn regularojn. La regularoj, eĉ se vi havas ĉion aŭtomatigitan, povas esti tre simplaj. El la serio "kuru tian kaj tian skripton", "klaku tian markobutonon en la vojo 53" kaj tiel plu - sed ĉi tio devas esti ia ĝusta listo de agoj.
Kaj ĉio ŝajnas klara. Ŝanĝi reproduktadon estas bagatela tasko, aŭ ĝi ŝanĝos sin. Reskribi domajnan nomon en DNS estas de la sama serio. La problemo estas, ke kiam tia projekto malsukcesas, paniko komenciĝas, kaj eĉ la plej fortaj, barbaj administrantoj povas esti susceptibles al ĝi. Sen klaraj instrukcioj "malfermu la terminalon, venu ĉi tien, la adreso de nia servilo ankoraŭ estas tia", estas malfacile plenumi la 5-minutan tempolimon asignitan por reanimado. Nu, krome, kiam ni uzas ĉi tiujn regularojn, estas facile registri iujn ŝanĝojn en la infrastrukturo, ekzemple, kaj ŝanĝi la regularojn laŭe.
Nu, se la rezerva sistemo estas tre kompleksa kaj iam ni eraris, tiam ni povas detrui nian rezervan retejon, kaj krome igi la datumojn en kukurbo en ambaŭ retejoj - tio estos tute malĝoja.
Ekzemplo numero kvin, kompleta hardcore
Internacia servo kun centoj da milionoj da uzantoj tra la mondo. Ĉiuj horzonoj ekzistas, alta ŝarĝo ĉe maksimuma rapideco, vi tute ne povas kuŝi. Minuton — kaj estos malĝoje. Kion fari? Rezervu, denove, laŭ la plena programo. Ni faris ĉion, pri kio mi parolis en la antaŭa ekzemplo, kaj iom pli. Ideala mondo, kaj nia infrastrukturo estas laŭ ĉiuj konceptoj de IaaC devops. Tio estas, ĉio estas en git, kaj vi simple premas la butonon.
Kio mankas? Unu - ekzercoj. Estas neeble sen ili. Ŝajnas, ke ĉio estas perfekta ĉe ni, ni ĝenerale havas ĉion sub kontrolo. Ni premas la butonon, ĉio okazas. Eĉ se tiel estas - kaj ni komprenas, ke ĝi ne okazas tiel - nia sistemo interagas kun iuj aliaj sistemoj. Ekzemple, ĉi tio estas dns de itinero 53, s3-stokado, integriĝo kun iu api. Ni ne povos antaŭvidi ĉion en ĉi tiu spekula eksperimento. Kaj ĝis ni efektive tiros la ŝaltilon, ni ne scios ĉu ĝi funkcios aŭ ne.
Tio verŝajne estas ĉio. Ne maldiligentu aŭ troigu ĝin. Kaj la tempodaŭro estu kun vi!
fonto: www.habr.com