Sa tag-araw, ang parehong aktibidad sa pagbili at ang intensity ng mga pagbabago sa imprastraktura ng mga proyekto sa web ay tradisyonal na bumababa, sabi sa amin ni Captain Obvious. Simple lang dahil kahit ang mga IT specialist minsan ay nagbabakasyon. At CTO din. Ito ay mas mahirap para sa mga nananatili sa opisina, ngunit hindi iyon ang punto ngayon: marahil iyon ang dahilan kung bakit ang tag-araw ay ang pinakamahusay na panahon upang dahan-dahang pag-isipan ang umiiral na pamamaraan ng pagpapareserba at gumawa ng isang plano upang mapabuti ito. At ang karanasan ni Yegor Andreev mula sa , na binanggit niya sa kumperensya .
Mayroong ilang mga pitfalls na maaari mong mahulog kapag gumagawa ng mga backup na site. At talagang imposibleng mahuli sa kanila. At ang sumisira sa atin sa lahat ng ito, tulad ng sa maraming iba pang bagay, ay ang pagiging perpekto at... katamaran. Sinusubukan naming gawin ang lahat, lahat, lahat nang perpekto, ngunit hindi namin kailangang gawin ito nang perpekto! Kailangan mo lamang gawin ang ilang mga bagay, ngunit gawin ang mga ito nang tama, kumpletuhin ang mga ito upang gumana nang maayos.
Ang Failover ay hindi isang uri ng nakakatuwang bagay na nakakatuwang "maging ito"; ito ay isang bagay na dapat gumawa ng eksaktong isang bagay - bawasan ang downtime upang ang serbisyo, ang kumpanya, ay nawawalan ng mas kaunting pera. At sa lahat ng paraan ng reserbasyon, iminumungkahi kong isipin ang sumusunod na konteksto: nasaan ang pera?
Unang bitag: kapag nagtayo tayo ng malaki, maaasahang mga sistema at nasangkot sa redundancy, binabawasan natin ang bilang ng mga aksidente. Ito ay isang kakila-kilabot na maling kuru-kuro. Kapag nasangkot tayo sa redundancy, malamang na madagdagan natin ang bilang ng mga aksidente. At kung gagawin natin ang lahat ng tama, pagkatapos ay sama-sama nating bawasan ang downtime. Magkakaroon ng mas maraming aksidente, ngunit magaganap ang mga ito sa mas mababang gastos. Ano ang reserbasyon? - ito ay isang komplikasyon ng sistema. Masama ang anumang komplikasyon: mayroon kaming mas maraming cogs, mas maraming gear, sa madaling salita, mas maraming elemento - at, samakatuwid, mas mataas na pagkakataon na masira. At magbebreak talaga sila. At mas madalas silang mag-break. Isang simpleng halimbawa: sabihin nating mayroon tayong website na may PHP at MySQL. At ito ay mapilit na kailangang ireserba.
Shtosh (c) Kinukuha namin ang pangalawang site, bumuo ng magkaparehong sistema... Ang pagiging kumplikado ay nagiging dalawang beses na mas mahusay - mayroon kaming dalawang entity. Naglalabas din kami ng isang tiyak na lohika para sa paglilipat ng data mula sa isang site patungo sa isa pa - iyon ay, pagtitiklop ng data, pagkopya ng static na data, at iba pa. Kaya, ang lohika ng pagtitiklop ay kadalasang napakakumplikado, at samakatuwid, ang kabuuang pagiging kumplikado ng sistema ay maaaring hindi 2, ngunit 3, 5, 10 beses na mas malaki.
Pangalawang bitag: kapag bumuo tayo ng napakalaking kumplikadong sistema, pinapantasya natin kung ano ang gusto nating makuha sa huli. Voila: gusto naming makakuha ng isang napaka-maaasahang system na gumagana nang walang anumang downtime, lumipat sa kalahating segundo (o mas mabuti pa, kaagad), at sinimulan naming gawin ang mga pangarap. Ngunit mayroon ding isang nuance dito: mas maikli ang nais na oras ng paglipat, nagiging mas kumplikado ang lohika ng system. Kung mas kumplikado ang kailangan nating gawin ang lohika na ito, mas madalas na masira ang sistema. At maaari kang mapunta sa isang napaka-hindi kasiya-siyang sitwasyon: sinusubukan namin nang buong lakas na bawasan ang downtime, ngunit sa katunayan ay ginagawa naming mas kumplikado ang lahat, at kapag nagkamali, ang downtime ay hahaba pa. Dito mo madalas nahuhuli ang iyong sarili na nag-iisip: well... mas mabuting huwag kang magpareserba. Mas mabuti kung ito ay gumana nang mag-isa at may naiintindihan na downtime.
Paano mo ito lalabanan? Kailangan nating ihinto ang pagsisinungaling sa ating sarili, itigil ang pagpuri sa ating sarili na tayo ay gagawa ng isang sasakyang pangkalawakan dito ngayon, ngunit sapat na maunawaan kung gaano katagal ang proyekto ay maaaring magsinungaling. At para sa pinakamataas na oras na ito, pipiliin namin kung anong mga pamamaraan ang aktwal naming gagamitin upang mapataas ang pagiging maaasahan ng aming system.
Oras na para sa βmga kwento mula sa wβ... mula sa buhay, siyempre.
Halimbawa numero uno
Isipin ang isang website ng business card para sa Pipe Rolling Plant No. 1 sa lungsod ng N. Nakasaad sa malalaking titik - PIPE ROLLING PLANT No. 1. Nasa ibaba lamang ang slogan: "Ang aming mga tubo ay ang mga pinakabilog na tubo sa N." At sa ibaba ay ang numero ng telepono ng CEO at ang kanyang pangalan. Naiintindihan namin na kailangan mong magpareserba - ito ay isang napakahalagang bagay! Simulan nating alamin kung ano ang binubuo nito. Html-statics - iyon ay, isang pares ng mga larawan kung saan ang pangkalahatang tagapamahala, sa katunayan, ay tinatalakay ang ilang uri ng susunod na pakikitungo sa mesa sa banyo kasama ang kanyang kapareha. Nagsisimula kaming mag-isip tungkol sa downtime. Ito ay dumating sa isip: kailangan mong humiga doon ng limang minuto, hindi na. At pagkatapos ay lumitaw ang tanong: gaano karaming mga benta ang mayroon mula sa aming site sa pangkalahatan? Magkano-magkano? Ano ang ibig sabihin ng "zero"? At ang ibig sabihin ay: dahil ginawa ng heneral ang lahat ng apat na transaksyon noong nakaraang taon sa parehong mesa, kasama ang parehong mga tao kung kanino sila pumunta sa banyo at umupo sa mesa. At naiintindihan namin na kahit na ang site ay umupo nang isang araw, walang kakila-kilabot na mangyayari.
Batay sa panimulang impormasyon, mayroong isang araw upang itaas ang kuwentong ito. Simulan natin ang pag-iisip tungkol sa isang redundancy scheme. At pipiliin namin ang pinakaperpektong redundancy scheme para sa halimbawang ito: hindi kami gumagamit ng redundancy. Ang buong bagay na ito ay maaaring itaas ng sinumang admin sa loob ng kalahating oras na may mga smoke break. Mag-install ng web server, magdagdag ng mga file - iyon lang. Ito ay gagana. Hindi mo kailangang bantayan ang anumang bagay, hindi mo kailangang bigyang-pansin ang anumang bagay. Iyon ay, ang konklusyon mula sa halimbawa bilang isa ay medyo halata: ang mga serbisyo na hindi kailangang ireserba ay hindi kailangang ireserba.
Halimbawa bilang dalawa
Blog ng kumpanya: ang mga espesyal na sinanay na tao ay nagsusulat ng balita doon, nakibahagi kami sa ganito at ganoong eksibisyon, ngunit naglabas kami ng isa pang bagong produkto, at iba pa. Sabihin nating ito ay karaniwang PHP na may WordPress, isang maliit na database at kaunting static. Siyempre, naiisip muli na hindi ka dapat humiga sa anumang pagkakataon - "hindi hihigit sa limang minuto!" Iyon lang. Pero pag-isipan pa natin. Ano ang ginagawa ng blog na ito? Ang mga tao ay pumupunta doon mula sa Yandex, mula sa Google batay sa ilang mga query, sa organikong paraan. Malaki. May kinalaman ba ang mga benta dito? Epiphany: hindi talaga. Ang trapiko ng advertising ay napupunta sa pangunahing site, na nasa ibang makina. Simulan natin ang pag-iisip tungkol sa isang booking scheme. Sa mabuting paraan, kailangan itong itaas sa loob ng ilang oras, at mainam na paghandaan ito. Makatuwirang kumuha ng makina mula sa isa pang data center, i-roll ang kapaligiran dito, iyon ay, isang web server, PHP, WordPress, MySQL, at iwanan ito doon. Sa sandaling naiintindihan namin na ang lahat ay nasira, kailangan naming gawin ang dalawang bagay - ilunsad ang mysql dump 50 metro, lilipad ito doon sa isang minuto, at maglalabas ng isang tiyak na bilang ng mga larawan mula sa backup doon. Wala rin ito para alam ng Diyos kung gaano katagal. Kaya, sa kalahating oras ang buong bagay ay tumataas. Walang pagtitiklop, o patawarin ako ng Diyos, automatic failover. Konklusyon: kung ano ang mabilis nating mailalabas mula sa isang backup ay hindi kailangang i-back up.
Halimbawa bilang tatlo, mas kumplikado
Online na tindahan. Ang PhP na may bukas na puso ay medyo na-tweak, mysql na may matatag na base. Napakaraming static (pagkatapos ng lahat, ang online na tindahan ay may magagandang larawan sa HD at lahat ng bagay na iyon), Redis para sa session at Elasticsearch para sa paghahanap. Nagsisimula kaming mag-isip tungkol sa downtime. At dito, siyempre, malinaw na ang isang online na tindahan ay hindi maaaring humiga nang walang sakit sa loob ng isang araw. Pagkatapos ng lahat, habang tumatagal, mas maraming pera ang nawawala sa atin. Ito ay nagkakahalaga ng pagpapabilis. Magkano? Sa tingin ko kung humiga kami ng isang oras, walang mababaliw. Oo, may mawawala sa atin, pero kung magsisikap tayo, lalo lang itong lalala. Tinutukoy namin ang isang scheme ng downtime na pinapayagan bawat oras.
Paano maipareserba ang lahat ng ito? Kailangan mo ng kotse sa anumang kaso: ang isang oras ng oras ay medyo kaunti. Mysql: dito kailangan na natin ng replication, live replication, dahil sa isang oras 100 GB ay malamang na hindi na maidagdag sa dump. Statics, mga larawan: muli, sa isang oras 500 GB ay maaaring walang oras upang maidagdag. Samakatuwid, mas mahusay na kopyahin kaagad ang mga larawan. Redis: dito nagiging kawili-wili ang mga bagay. Sa Redis, iniimbak ang mga session - hindi natin ito basta-basta kunin at ibaon. Dahil hindi ito magiging napakahusay: ang lahat ng mga gumagamit ay mai-log out, ang kanilang mga basket ay mawawalan ng laman, at iba pa. Ang mga tao ay mapipilitang ipasok muli ang kanilang username at password, at maraming tao ang maaaring humiwalay at hindi makumpleto ang pagbili. Muli, bababa ang mga conversion. Sa kabilang banda, ang Redis ay direktang napapanahon, na ang mga huling naka-log-in na user ay malamang na hindi rin kailangan. At ang isang magandang kompromiso ay kunin ang Redis at ibalik ito mula sa isang backup mula kahapon, o, kung gagawin mo ito bawat oras, mula sa isang oras na nakalipas. Sa kabutihang palad, ang pagpapanumbalik nito mula sa isang backup ay nangangahulugan ng pagkopya ng isang file. At ang pinakakawili-wiling kwento ay ang Elasticsearch. Sino ang naka-pick up ng MySQL replication? Sino ang naka-pick up ng Elasticsearch replication? At para kanino ito gumana nang normal pagkatapos? Ang ibig kong sabihin ay nakikita natin ang isang partikular na entity sa ating system. Mukhang kapaki-pakinabang - ngunit ito ay kumplikado.
Kumplikado sa kahulugan na ang ating mga kapwa inhinyero ay walang karanasan sa pagtatrabaho dito. O may negatibong karanasan. O naiintindihan namin na ito ay medyo bagong teknolohiya pa rin na may mga nuances o hilaw. Sa tingin namin... Damn, malusog din ang elastic, matagal din itong maibalik mula sa backup, ano ang dapat kong gawin? Naiintindihan namin na ang elastic sa aming kaso ay ginagamit para sa paghahanap. Paano nagbebenta ang aming online na tindahan? Pumunta kami sa mga marketer at nagtatanong kung saan nanggaling ang mga tao. Sumasagot sila: "90% mula sa Yandex Market ay direktang dumarating sa card ng produkto." At bibili man sila o hindi. Samakatuwid, ang paghahanap ay kailangan ng 10% ng mga user. At ang pagpapanatiling nababanat na pagtitiklop, lalo na sa pagitan ng iba't ibang mga sentro ng data sa iba't ibang mga zone, ay talagang may maraming mga nuances. Aling labasan? Kumuha kami ng nababanat mula sa isang nakareserbang site at walang ginagawa dito. Kung magtatagal ang usapin, malamang na itaas natin ito balang araw, ngunit hindi ito tiyak. Sa totoo lang, ang konklusyon ay pareho, plus o minus: kami, muli, ay hindi nagrereserba ng mga serbisyo na hindi nakakaapekto sa pera. Upang panatilihing mas simple ang diagram.
Halimbawa numero apat, mas mahirap
Integrator: pagbebenta ng mga bulaklak, pagtawag ng taxi, pagbebenta ng mga kalakal, sa pangkalahatan, kahit ano. Isang seryosong bagay na gumagana 24/7 para sa malaking bilang ng mga user. Sa isang ganap na kawili-wiling stack, kung saan may mga kagiliw-giliw na base, solusyon, mataas na pagkarga, at higit sa lahat, masakit na humiga nang higit sa 5 minuto. Hindi lamang at hindi masyado dahil ang mga tao ay hindi bibili, ngunit dahil makikita ng mga tao na ang bagay na ito ay hindi gumagana, sila ay magalit at maaaring hindi na bumalik.
OK. Limang minuto. Ano ang gagawin natin dito? Sa kasong ito, kami, tulad ng mga nasa hustong gulang, ay ginagamit ang lahat ng pera upang bumuo ng isang tunay na backup na site, na may pagkopya ng lahat, at marahil ay awtomatiko pa ang paglipat sa site na ito hangga't maaari. At bilang karagdagan dito, kailangan mong tandaan na gawin ang isang mahalagang bagay: sa totoo lang, isulat ang mga regulasyon sa paglipat. Ang mga regulasyon, kahit na awtomatiko mo ang lahat, ay maaaring maging napaka-simple. Mula sa seryeng "patakbuhin ang ganoon at ganoong ansible na script", "i-click ang ganito at ganoong checkbox sa ruta 53" at iba pa - ngunit ito ay dapat na isang uri ng eksaktong listahan ng mga aksyon.
At tila malinaw ang lahat. Ang pagpapalit ng replikasyon ay isang maliit na gawain, o ito ay lilipat mismo. Ang muling pagsusulat ng domain name sa DNS ay mula sa parehong serye. Ang problema ay kapag nabigo ang naturang proyekto, magsisimula ang gulat, at kahit na ang pinakamalakas at may balbas na mga admin ay maaaring maging madaling kapitan dito. Nang walang malinaw na mga tagubilin "buksan ang terminal, halika dito, ang address ng aming server ay ganito pa rin," mahirap matugunan ang 5 minutong limitasyon sa oras na inilaan para sa resuscitation. At saka, kapag ginamit namin ang mga regulasyong ito, madaling magtala ng ilang pagbabago sa imprastraktura, halimbawa, at baguhin ang mga regulasyon nang naaayon.
Buweno, kung ang sistema ng reserbasyon ay napaka-kumplikado at sa ilang mga punto ay nagkamali kami, maaari naming sirain ang aming backup na site, at bilang karagdagan ay gawing kalabasa ang data sa parehong mga site - ito ay magiging ganap na malungkot.
Halimbawa bilang limang, kumpletong hardcore
Isang internasyonal na serbisyo na may daan-daang milyong user sa buong mundo. Ang lahat ng mga time zone ay mayroon, mataas na pagkarga sa pinakamataas na bilis, hindi ka maaaring humiga. Isang minuto - at ito ay magiging malungkot. Anong gagawin? Magreserba, muli, ayon sa buong programa. Ginawa namin ang lahat ng napag-usapan ko sa nakaraang halimbawa, at kaunti pa. Isang perpektong mundo, at ang aming imprastraktura ay ayon sa lahat ng mga konsepto ng IaaC devops. Iyon ay, ang lahat ay nasa git, at pinindot mo lang ang pindutan.
Anong nawawala? Isa - pagsasanay. Imposible kung wala sila. Tila ang lahat ay perpekto sa amin, sa pangkalahatan ay nasa ilalim ng kontrol ang lahat. Pinindot namin ang pindutan, nangyayari ang lahat. Kahit na ganito - at naiintindihan namin na hindi ito nangyayari sa ganitong paraan - nakikipag-ugnayan ang aming system sa ilang iba pang mga system. Halimbawa, ito ay dns mula sa ruta 53, imbakan ng s3, pagsasama sa ilang api. Hindi namin mahulaan ang lahat sa speculative experiment na ito. At hangga't hindi talaga natin hinihila ang switch, hindi natin malalaman kung gagana ito o hindi.
Malamang yun lang. Huwag maging tamad o sobra-sobra. At maaaring ang uptime ay kasama mo!
Pinagmulan: www.habr.com