Karon, ang serbisyo sa Bitrix24 wala’y gatusan ka gigabit nga trapiko, ni adunay daghang mga panon sa mga server (bisan kung, siyempre, adunay pipila nga mga naa). Apan alang sa daghang mga kliyente kini ang panguna nga himan alang sa pagtrabaho sa kompanya; kini usa ka tinuud nga aplikasyon nga kritikal sa negosyo. Busa, walay paagi nga mahulog. Unsa kaha kung ang pagkahagsa nahitabo, apan ang serbisyo "naayo" kadali nga wala’y nakamatikod bisan unsa? Ug sa unsang paagi posible nga ipatuman ang failover nga dili mawala ang kalidad sa trabaho ug ang gidaghanon sa mga kliyente? Si Alexander Demidov, direktor sa mga serbisyo sa panganod sa Bitrix24, namulong alang sa among blog kung giunsa ang pag-uswag sa sistema sa reserbasyon sa 7 ka tuig nga paglungtad sa produkto.
"Gilunsad namon ang Bitrix24 ingon usa ka SaaS 7 ka tuig ang milabay. Ang nag-unang kalisud tingali mao ang mosunod: sa wala pa kini gilusad sa publiko isip SaaS, kini nga produkto naglungtad lamang sa format sa usa ka boxed solution. Gipalit kini sa mga kliyente gikan kanamo, gi-host kini sa ilang mga server, nagbutang usa ka portal sa korporasyon - usa ka kinatibuk-ang solusyon alang sa komunikasyon sa empleyado, pagtipig sa file, pagdumala sa buluhaton, CRM, kana ra. Ug sa 2012, nakahukom kami nga gusto namong ilunsad kini isip SaaS, pagdumala niini sa among kaugalingon, pagsiguro sa pagtugot sa sayup ug kasaligan. Nakakuha kami og kasinatian sa dalan, tungod kay hangtud niadto wala kami niini - kami mga tiggama lamang sa software, dili mga service provider.
Kung naglansad sa serbisyo, nasabtan namon nga ang labing hinungdanon nga butang mao ang pagsiguro sa pagtugot sa sayup, kasaligan ug kanunay nga pagkaanaa sa serbisyo, tungod kay kung ikaw adunay usa ka yano nga ordinaryo nga website, usa ka tindahan, pananglitan, ug kini nahulog kanimo ug naglingkod didto usa ka oras, ikaw lang ang nag-antos, nawad-an ka og mga order , nawad-an ka og mga kliyente, apan alang sa imong kliyente mismo, kini dili kaayo kritikal alang kaniya. Nasuko siya, siyempre, apan miadto siya ug gipalit kini sa laing site. Ug kung kini usa ka aplikasyon diin ang tanan nga trabaho sa sulod sa kompanya, komunikasyon, mga desisyon gihigot, nan ang labing hinungdanon nga butang mao ang pag-angkon sa pagsalig sa mga tiggamit, nga mao, dili sila pasagdan ug dili mahulog. Tungod kay ang tanan nga trabaho mahimong mahunong kung ang usa ka butang sa sulod dili molihok.
Bitrix.24 isip SaaS
Among gitigom ang unang prototype usa ka tuig sa wala pa ang paglusad sa publiko, niadtong 2011. Among gitigom kini sulod sa mga usa ka semana, gitan-aw kini, gituyok-tuyok kini - nagtrabaho pa gani. Kana mao, mahimo ka nga moadto sa porma, isulod ang ngalan sa portal didto, usa ka bag-ong portal ang maablihan, ug usa ka base sa gumagamit ang mahimo. Among gitan-aw kini, gisusi ang produkto sa prinsipyo, gibasura kini, ug gipadayon kini sa pagpino sulod sa tibuok tuig. Tungod kay kami adunay usa ka dako nga buluhaton: dili kami gusto nga maghimo duha ka lainlaing mga base sa code, dili kami gusto nga suportahan ang usa ka lahi nga giputos nga produkto, lahi nga mga solusyon sa panganod - gusto namon nga buhaton kini tanan sa usa ka code.
Usa ka kasagaran nga aplikasyon sa web niadtong panahona mao ang usa ka server diin ang pipila ka PHP code nagdagan, usa ka mysql database, mga file nga gi-upload, mga dokumento, mga hulagway gibutang sa upload folder - maayo, kini tanan nagtrabaho. Alaut, imposible nga maglansad usa ka kritikal nga lig-on nga serbisyo sa web gamit kini. Didto, ang gi-apod-apod nga cache wala gisuportahan, ang pagkopya sa database wala gisuportahan.
Giporma namo ang mga kinahanglanon: kini ang katakus nga mahimutang sa lain-laing mga lokasyon, pagsuporta sa pagkopya, ug labing maayo nga mahimutang sa lainlaing mga sentro sa datos nga giapod-apod sa heyograpiya. Ibulag ang lohika sa produkto ug, sa tinuud, pagtipig sa datos. Makahimo sa dinamikong pagsukod sumala sa karga, ug tugotan ang mga estatika sa hingpit. Gikan sa kini nga mga konsiderasyon, sa tinuud, ang mga kinahanglanon alang sa produkto mitumaw, nga among gipino sa dagan sa tuig. Niini nga panahon, sa plataporma, nga nahimo nga nagkahiusa - alang sa mga kahon nga solusyon, alang sa among kaugalingong serbisyo - naghimo kami og suporta alang sa mga butang nga among gikinahanglan. Suporta alang sa mysql replication sa lebel sa produkto mismo: nga mao, ang developer nga nagsulat sa code wala maghunahuna kung giunsa ang pag-apod-apod sa iyang mga hangyo, gigamit niya ang among api, ug nahibal-an namon kung giunsa ang husto nga pag-apod-apod sa pagsulat ug pagbasa sa mga hangyo tali sa mga agalon ug mga ulipon.
Naghimo kami og suporta sa lebel sa produkto alang sa nagkalain-laing mga cloud object storage: google storage, amazon s3, plus suporta alang sa open stack swift. Busa, kini sayon alang kanamo isip usa ka serbisyo ug alang sa mga developers nga nagtrabaho uban sa usa ka packaged nga solusyon: kung gamiton lang nila ang among API alang sa trabaho, wala sila maghunahuna kung asa ang file sa katapusan maluwas, lokal sa file system o sa object file storage.
Ingon usa ka sangputanan, nakahukom dayon kami nga magreserba kami sa lebel sa tibuuk nga sentro sa datos. Kaniadtong 2012, naglansad kami sa hingpit sa Amazon AWS tungod kay naa na kami kasinatian sa kini nga plataporma - ang among kaugalingon nga website gi-host didto. Nadani kami sa kamatuoran nga sa matag rehiyon ang Amazon adunay ubay-ubay nga mga availability zone - sa pagkatinuod, (sa ilang terminolohiya) daghang mga sentro sa datos nga labaw pa o dili kaayo independente sa usag usa ug nagtugot kanamo sa pagreserba sa lebel sa tibuok data center: kung kini kalit nga mapakyas, ang mga database gisundog nga master-master, ang mga web application server gi-back up, ug ang static nga data gibalhin sa s3 object storage. Ang load balanse - nianang panahona sa Amazon elb, apan sa wala madugay miabut kami sa among kaugalingong load balancers, tungod kay nagkinahanglan kami og mas komplikado nga lohika.
Ang ilang gusto mao ang ilang nakuha...
Ang tanan nga sukaranan nga mga butang nga gusto namon nga masiguro - ang pagtugot sa sayup sa mga server mismo, mga aplikasyon sa web, mga database - ang tanan nagtrabaho nga maayo. Ang pinakasimple nga senaryo: kung ang usa sa among mga aplikasyon sa web mapakyas, nan ang tanan yano ra - kini gipalong gikan sa pagbalanse.
Ang balancer (niadtong panahona kini ang Amazon's elb) nagtimaan sa mga makina nga wala na sa kahusay nga dili maayo ug gipalong ang pag-apod-apod sa load sa kanila. Ang autoscaling sa Amazon nagtrabaho: sa dihang ang load mitubo, ang mga bag-ong makina gidugang sa autoscaling nga grupo, ang load giapod-apod ngadto sa bag-ong mga makina - ang tanan maayo. Uban sa among mga balanse, ang lohika parehas ra: kung adunay mahitabo sa server sa aplikasyon, tangtangon namon ang mga hangyo gikan niini, ilabay kini nga mga makina, magsugod mga bag-o ug magpadayon sa pagtrabaho. Ang laraw nausab gamay sa daghang mga tuig, apan nagpadayon sa pagtrabaho: kini yano, masabtan, ug wala’y mga kalisud niini.
Nagtrabaho kami sa tibuuk kalibutan, lahi ang mga peak sa load sa kostumer, ug, sa usa ka mahigalaon nga paagi, kinahanglan namon nga mahimo ang piho nga trabaho sa serbisyo sa bisan unsang mga sangkap sa among sistema bisan unsang oras - nga wala mamatikdan sa mga kostumer. Busa, kami adunay oportunidad sa pagpalong sa database gikan sa operasyon, pag-apod-apod sa load ngadto sa ikaduha nga data center.
Giunsa kini tanan? — Gibalhin namon ang trapiko sa usa ka nagtrabaho nga sentro sa datos - kung adunay usa ka aksidente sa data center, nan hingpit, kung kini ang among giplano nga trabaho nga adunay usa ka database, nan among gibalhin ang bahin sa trapiko nga nagserbisyo sa kini nga mga kliyente sa usa ka ikaduha nga sentro sa datos, nga gisuspinde kini replikasyon. Kung gikinahanglan ang bag-ong mga makina alang sa mga aplikasyon sa web tungod kay ang load sa ikaduhang data center mitaas, sila awtomatikong magsugod. Gihuman namo ang trabaho, gipahiuli ang replikasyon, ug gibalik namo ang tibuok nga load. Kung kinahanglan namon nga i-salamin ang pipila ka trabaho sa ikaduha nga DC, pananglitan, pag-install sa mga update sa sistema o pagbag-o sa mga setting sa ikaduha nga database, nan, sa kinatibuk-an, gisubli namon ang parehas nga butang, sa pikas nga direksyon. Ug kung kini usa ka aksidente, nan buhaton namon ang tanan nga wala’y hinungdan: gigamit namon ang mekanismo sa mga tigdumala sa panghitabo sa sistema sa pag-monitor. Kung daghang mga tseke ang ma-trigger ug ang kahimtang moadto sa kritikal, nan among gipadagan kini nga handler, usa ka handler nga makahimo niini o kana nga lohika. Alang sa matag database, among gitino kung unsang server ang failover niini, ug kung diin kinahanglan nga ibalhin ang trapiko kung dili kini magamit. Sa kasaysayan, gigamit namo ang nagios o ang pipila sa mga tinidor niini sa usa ka porma o lain. Sa prinsipyo, ang susama nga mga mekanismo anaa sa halos bisan unsang sistema sa pagmonitor; wala pa kami mogamit bisan unsa nga mas komplikado pa, apan tingali sa umaabot nga adlaw kami mogamit. Karon ang pag-monitor na-trigger tungod sa pagkadili magamit ug adunay katakus sa pagbalhin sa usa ka butang.
Gi-reserve na ba namo ang tanan?
Daghan kami mga kliyente gikan sa USA, daghang mga kliyente gikan sa Europe, daghang mga kliyente nga mas duol sa Sidlakan - Japan, Singapore ug uban pa. Siyempre, usa ka dako nga bahin sa mga kliyente ang naa sa Russia. Sa ato pa, ang trabaho wala sa usa ka rehiyon. Ang mga tiggamit gusto sa usa ka dali nga tubag, adunay mga kinahanglanon sa pagtuman sa lain-laing mga lokal nga mga balaod, ug sa sulod sa matag rehiyon kita reserba sa duha ka data centers, plus adunay pipila ka mga dugang nga mga serbisyo, nga, pag-usab, mao ang sayon nga ibutang sa sulod sa usa ka rehiyon - alang sa mga kliyente nga anaa sa kini nga rehiyon nagtrabaho. Ang mga tigdumala sa REST, mga tigtagad sa pagtugot, dili kaayo sila kritikal alang sa operasyon sa kliyente sa kinatibuk-an, mahimo nimo silang ibalhin sa usa ka gamay nga madawat nga paglangan, apan dili nimo gusto nga usbon ang ligid kung giunsa kini pag-monitor ug kung unsa ang buhaton. uban kanila. Busa, kami naningkamot sa paggamit sa kasamtangan nga mga solusyon sa maximum, kay sa pagpalambo sa usa ka matang sa katakus sa dugang nga mga produkto. Ug sa usa ka lugar nga wala’y hinungdan nga gigamit namon ang pagbalhin sa lebel sa DNS, ug gitino namon ang kadasig sa serbisyo sa parehas nga DNS. Ang Amazon adunay serbisyo nga Route 53, apan dili lang kini DNS diin mahimo ka maghimo mga entri ug mao kana - labi ka labi ka dali ug dali. Pinaagi niini makahimo ka og geo-distributed nga mga serbisyo nga adunay mga geolocation, kung imong gamiton kini aron mahibal-an kung diin gikan ang kliyente ug hatagan siya og piho nga mga rekord - uban sa tabang niini mahimo ka nga magtukod og mga arkitektura sa failover. Ang parehas nga mga pagsusi sa kahimsog gi-configure sa Route 53 mismo, imong gitakda ang mga endpoint nga gibantayan, gitakda ang mga sukatan, gitakda kung unsang mga protocol aron mahibal-an ang "liveness" sa serbisyo - tcp, http, https; itakda ang kasubsob sa mga tseke nga magdeterminar kon ang serbisyo buhi o dili. Ug sa DNS mismo imong gipiho kung unsa ang mahimong panguna, kung unsa ang mahimong sekondarya, kung asa ibalhin kung ang pagsusi sa kahimsog ma-trigger sa sulod sa ruta 53. Ang tanan nga kini mahimo sa uban pang mga himan, apan ngano nga kini kombenyente - gibutang namon kini sa makausa ug unya ayaw paghunahuna mahitungod niini sa tanan kon sa unsang paagi kita magsusi, sa unsa nga paagi kita mobalhin: ang tanan molihok sa iyang kaugalingon.
Ang unang "apan": sa unsa nga paagi ug unsa ang pagreserba sa ruta 53 mismo? Who knows, what if naay mahitabo niya? Maayo na lang, wala kami nakatunob niini nga rake, apan pag-usab, ako adunay usa ka istorya sa unahan kung ngano nga kami naghunahuna nga kinahanglan pa namon nga magpareserba. Dinhi among gibutang ang mga straw alang sa among kaugalingon nga daan. Daghang mga higayon sa usa ka adlaw naghimo kami usa ka kompleto nga pagdiskarga sa tanan nga mga sona nga naa kanamo sa ruta 53. Gitugotan ka sa API sa Amazon nga dali nimo ipadala kini sa JSON, ug kami adunay daghang mga backup nga server diin among gi-convert kini, gi-upload kini sa porma sa mga configs ug adunay, sa halos pagsulti, usa ka backup nga configuration. Kung adunay mahitabo, mahimo namon nga dali nga i-deploy kini nga mano-mano nga dili mawala ang datos sa mga setting sa DNS.
Ikaduha "apan": Unsa ang naa sa litrato nga wala pa gireserba? Ang balanse mismo! Ang among pag-apod-apod sa mga kliyente sa rehiyon gihimo nga yano kaayo. Kami adunay mga domain nga bitrix24.ru, bitrix24.com, .de - karon adunay 13 ka lainlain, nga naglihok sa lainlaing mga zone. Miabot kami sa mosunod: ang matag rehiyon adunay kaugalingong mga balanse. Kini naghimo nga mas sayon sa pag-apod-apod sa mga rehiyon, depende kung asa ang peak load sa network. Kung kini usa ka kapakyasan sa lebel sa usa ka balanse, nan kini gikuha gikan sa serbisyo ug gikuha gikan sa dns. Kung adunay pipila ka mga problema sa usa ka grupo sa mga balanse, nan sila gipaluyohan sa ubang mga site, ug ang pagbalhin tali kanila gihimo gamit ang parehas nga ruta53, tungod kay tungod sa mubo nga TTL, ang pagbalhin mahitabo sa labing taas nga 2, 3, 5 minuto. .
Ikatulo "apan": Unsa ang wala pa gireserba? S3, tama nga. Sa dihang gibutang namo ang mga file nga among gitipigan alang sa mga tiggamit sa s3, kami sinsero nga mituo nga kini armor-piercing ug wala na kinahanglana nga magreserba bisan unsa didto. Apan gipakita sa kasaysayan nga lahi ang nahitabo. Sa kinatibuk-an, gihulagway sa Amazon ang S3 isip usa ka sukaranan nga serbisyo, tungod kay ang Amazon mismo naggamit sa S3 sa pagtipig sa mga imahe sa makina, mga config, mga hulagway sa AMI, mga snapshot ... Ug kung ang s3 nahagsa, sama sa nahitabo sa makausa sulod niining 7 ka tuig, basta kami naggamit. bitrix24, kini nagsunod niini sama sa usa ka fan Adunay usa ka bug-os nga hugpong sa mga butang nga moabut - kawalay katakus sa pagsugod sa mga virtual nga makina, pagkapakyas sa api, ug uban pa.
Ug ang S3 mahimong mahulog - kini nahitabo kausa. Busa, miabut kami sa mosunod nga laraw: pipila ka tuig na ang milabay walay seryoso nga mga pasilidad sa pagtipig sa mga butang sa publiko sa Russia, ug among gikonsiderar ang kapilian sa pagbuhat sa usa ka butang sa among kaugalingon... Maayo na lang, wala kami magsugod sa pagbuhat niini, tungod kay among buhaton. nakalot sa kahanas nga wala kanato, ug tingali makagubot. Karon ang Mail.ru adunay s3-compatible nga pagtipig, Yandex adunay kini, ug daghang uban pang mga provider ang adunay niini. Sa katapusan miabut kami sa ideya nga gusto namong makabaton, una, backup, ug ikaduha, ang abilidad sa pagtrabaho uban sa lokal nga mga kopya. Sa partikular nga rehiyon sa Russia, gigamit namon ang serbisyo sa Mail.ru Hotbox, nga nahiuyon sa API sa s3. Wala namo kinahanglana ang bisan unsang dagkong kausaban sa code sa sulod sa aplikasyon, ug among gihimo ang mosunod nga mekanismo: sa s3 adunay mga triggers nga nag-trigger sa paghimo/pagtangtang sa mga butang, ang Amazon adunay serbisyo nga gitawag og Lambda - kini usa ka serverless launching sa code nga ipatuman sa diha nga ang pipila ka mga trigger ma-trigger.
Gibuhat namo kini sa yano kaayo: kung ang among trigger mosunog, among ipatuman ang code nga magkopya sa butang ngadto sa Mail.ru storage. Aron hingpit nga maglansad sa trabaho sa lokal nga mga kopya sa datos, kinahanglan usab namon ang reverse synchronization aron ang mga kliyente nga naa sa bahin sa Russia makatrabaho sa pagtipig nga mas duol kanila. Hapit na makompleto sa mail ang mga nag-trigger sa pagtipig niini - posible nga himuon ang reverse synchronization sa lebel sa imprastraktura, apan sa pagkakaron gibuhat namon kini sa lebel sa among kaugalingon nga code. Kung nakita namon nga ang usa ka kliyente nag-post sa usa ka file, unya sa lebel sa code gibutang namon ang panghitabo sa usa ka pila, giproseso kini ug gibalikbalik ang pagkopya. Ngano nga kini dili maayo: kung maghimo kami usa ka matang sa trabaho sa among mga butang sa gawas sa among produkto, kana, pinaagi sa pipila nga paagi sa gawas, dili namon kini tagdon. Busa, maghulat kami hangtod sa katapusan, kung ang mga pag-trigger makita sa lebel sa pagtipig, aron bisan diin namon gipatuman ang code, ang butang nga moabut kanamo gikopya sa pikas nga direksyon.
Sa lebel sa code, girehistro namon ang duha nga pagtipig alang sa matag kliyente: ang usa giisip nga panguna, ang lain giisip nga usa ka backup. Kung maayo ang tanan, nagtrabaho kami sa pagtipig nga mas duol kanamo: kana mao, ang among mga kliyente nga naa sa Amazon, nagtrabaho sila sa S3, ug kadtong nagtrabaho sa Russia, nagtrabaho sila sa Hotbox. Kung ma-trigger ang bandila, kinahanglan nga konektado ang failover, ug ibalhin namon ang mga kliyente sa lain nga pagtipig. Mahimo natong susihon kini nga kahon nga independente sa rehiyon ug mahimo kining ibalhin balik-balik. Wala pa namo kini gigamit sa praktis, apan naghatag kami niini nga mekanismo ug naghunahuna kami nga sa umaabot nga adlaw kinahanglan namo kini nga switch ug magamit. Nahitabo na kini kausa.
Oh, ug ang Amazon milayas ...
Karong Abril nagtimaan sa anibersaryo sa pagsugod sa pag-block sa Telegram sa Russia. Ang labing naapektuhan nga provider nga nahulog sa ilawom niini mao ang Amazon. Ug, sa kasubo, ang mga kompanya sa Russia nga nagtrabaho sa tibuuk kalibutan labi nga nag-antus.
Kung ang kompanya global ug ang Russia usa ka gamay nga bahin alang niini, 3-5% - maayo, usa ka paagi o lain, mahimo nimo silang isakripisyo.
Kung kini usa ka lunsay nga kompanya sa Russia - sigurado ako nga kinahanglan kini nga mahimutang sa lokal - maayo, kini mahimong sayon alang sa mga tiggamit mismo, komportable, ug adunay gamay nga peligro.
Unsa kaha kung kini usa ka kompanya nga naglihok sa tibuuk kalibutan ug adunay gibana-bana nga managsama nga gidaghanon sa mga kliyente gikan sa Russia ug bisan diin sa tibuuk kalibutan? Ang pagkadugtong sa mga bahin hinungdanon, ug sila kinahanglan nga magtrabaho sa usag usa sa usa ka paagi o lain.
Sa katapusan sa Marso 2018, ang Roskomnadzor nagpadala ug usa ka sulat ngadto sa kinadak-ang mga operator nga nag-ingon nga sila nagplano sa pag-block sa pipila ka milyon nga Amazon IPs aron ma-block... ang Zello messenger. Salamat sa parehas nga mga tighatag - malampuson nila nga gi-leak ang sulat sa tanan, ug adunay pagsabut nga ang koneksyon sa Amazon mahimong mabungkag. Biyernes kadto, nagdagan kami sa kalisang sa among mga kauban gikan sa servers.ru, nga adunay mga pulong: "Mga higala, kinahanglan namon ang daghang mga server nga mahimutang dili sa Russia, dili sa Amazon, apan, pananglitan, sa usa ka lugar sa Amsterdam," aron nga makahimo sa labing menos sa usa ka paagi sa pag-instalar sa among kaugalingong VPN ug proxy didto alang sa pipila ka mga endpoint nga dili namo maimpluwensyahan sa bisan unsa nga paagi, pananglitan mga endponts sa sama nga s3 - dili kami makasulay sa pagpataas sa usa ka bag-ong serbisyo ug makakuha og lain ip, kami kinahanglan pa nimo nga makaabut didto. Sa pipila lang ka adlaw, among gi-set up kini nga mga server, gipaandar kini, ug, sa kinatibuk-an, nangandam sa higayon nga nagsugod ang blocking. Makapaikag nga ang RKN, nga nagtan-aw sa kaguliyang ug kalisang, miingon: "Dili, dili kami makababag bisan unsa karon." (Apan kini eksakto hangtod sa higayon nga ang Telegram nagsugod nga gibabagan.) Sa pag-set up sa mga kapabilidad sa bypass ug nahibal-an nga ang pag-block wala pa gipaila, kami, bisan pa, wala magsugod sa paghan-ay sa tibuuk nga butang. Oo, sa kaso lang.
Ug sa 2019, nagpuyo gihapon kami sa mga kondisyon sa pag-block. Gitan-aw nako kagabii: mga usa ka milyon nga IP ang padayon nga gibabagan. Tinuod, ang Amazon halos hingpit nga na-unblock, sa kinapungkayan niini nakaabot kini sa 20 ka milyon nga mga adres ... Sa kinatibuk-an, ang tinuod mao nga wala'y panag-uban, maayo nga pagkahiusa. Sa kalit. Mahimong wala kini tungod sa teknikal nga mga hinungdan - mga sunog, mga excavator, tanan kana. O, ingon sa atong nakita, dili hingpit nga teknikal. Busa, ang usa ka tawo nga dako ug dako, nga adunay ilang kaugalingon nga mga AS, mahimo nga makadumala niini sa ubang mga paagi - direkta nga pagkonektar ug uban pang mga butang naa na sa lebel sa l2. Apan sa usa ka yano nga bersyon, sama sa atoa o mas gamay pa, mahimo nimo, kung sakali, adunay redundancy sa lebel sa mga server nga gipataas sa laing lugar, gi-configure nga daan vpn, proxy, nga adunay kaarang nga dali nga ibalhin ang pagsumpo sa kanila sa mga bahin. nga kritikal alang sa imong koneksyon. Kini magamit alang kanamo labaw pa sa kausa, sa dihang nagsugod ang pag-block sa Amazon; sa pinakagrabe nga sitwasyon sa kaso, gitugotan lang namo ang trapiko sa S3 pinaagi kanila, apan sa hinay-hinay kining tanan nasulbad.
Unsaon pag reserba... ang tibuok provider?
Karon wala kami usa ka senaryo kung ang tibuuk nga Amazon nahulog. Kami adunay susama nga senaryo alang sa Russia. Sa Russia, gi-host kami sa usa ka tighatag, diin gipili namon nga adunay daghang mga site. Ug usa ka tuig na ang milabay nag-atubang kami og problema: bisan pa nga kini duha ka mga sentro sa datos, mahimong adunay mga problema na sa lebel sa network configuration sa provider nga makaapekto gihapon sa duha ka mga data center. Ug mahimo kaming dili magamit sa duha nga mga site. Syempre mao nay nahitabo. Natapos namon nga gikonsiderar pag-usab ang arkitektura sa sulod. Kini wala kaayo mausab, apan alang sa Russia kami karon adunay duha ka mga site, nga dili gikan sa sama nga provider, apan gikan sa duha ka lain-laing mga. Kung ang usa mapakyas, mahimo natong ibalhin sa lain.
Hypothetically, alang sa Amazon among gikonsiderar ang posibilidad sa pagreserba sa lebel sa laing provider; tingali ang Google, tingali ang uban pa... Apan hangtod karon among naobserbahan sa praktis nga samtang ang Amazon adunay mga aksidente sa lebel sa usa ka availability zone, ang mga aksidente sa lebel sa tibuok rehiyon talagsa ra. Busa, kami sa teoriya adunay ideya nga mahimo kaming maghimo usa ka "Amazon dili Amazon" nga reserbasyon, apan sa praktis dili pa kini ang kaso.
Pipila ka mga pulong mahitungod sa automation
Kinahanglan ba kanunay ang automation? Dinhi angay nga hinumdoman ang epekto sa Dunning-Kruger. Sa "x" axis mao ang atong kahibalo ug kasinatian nga atong naangkon, ug sa "y" axis mao ang pagsalig sa atong mga aksyon. Sa sinugdan wala kitay nahibaloan ug dili gayod sigurado. Dayon nahibal-an nato ang gamay ug nahimong mega-confident - kini ang gitawag nga "peak of stupidity", nga maayo nga gihulagway sa hulagway nga "dementia and courage". Unya nakakat-on kami og gamay ug andam na nga moadto sa gubat. Dayon kita motunob sa pipila ka mega-seryoso nga mga sayop ug makita ang atong mga kaugalingon sa usa ka walog sa pagkawalay paglaum, sa diha nga kita daw nahibalo sa usa ka butang, apan sa pagkatinuod kita wala mahibalo sa daghan. Dayon, samtang kita makabaton og kasinatian, kita mahimong mas masaligon.
Ang among lohika bahin sa lainlaing mga awtomatikong switch sa pipila nga mga aksidente maayo kaayo nga gihulagway sa kini nga graph. Nagsugod kami - wala kami nahibal-an kung unsaon pagbuhat bisan unsa, hapit tanan nga trabaho gihimo pinaagi sa kamot. Dayon among naamgohan nga mahimo namong ilakip ang automation sa tanan ug, sama, matulog nga malinawon. Ug sa kalit mitunob kami sa usa ka mega-rake: usa ka sayup nga positibo ang na-trigger, ug kami nagbalhinbalhin sa trapiko kung, sa maayong paagi, dili unta namon kini buhaton. Tungod niini, ang pagkopya naguba o uban pa - kini ang walog sa pagkawalay paglaum. Ug unya moabut kita sa pagsabut nga kinahanglan naton nga hisgutan ang tanan nga maalamon. Sa ato pa, makatarunganon nga magsalig sa automation, nga naghatag alang sa posibilidad sa sayup nga mga alarma. Apan! kung ang mga sangputanan mahimong makadaot, nan mas maayo nga ibilin kini sa pagbalhin sa katungdanan, sa mga enhinyero nga nag-duty, nga magsiguro ug mag-monitor nga adunay usa ka aksidente, ug himuon ang kinahanglan nga mga aksyon nga mano-mano...
konklusyon
Sulod sa 7 ka tuig, gikan sa kamatuoran nga sa diha nga ang usa ka butang nahulog, adunay kalisang-panic, ngadto sa pagsabut nga ang mga problema wala maglungtad, adunay mga buluhaton lamang, sila kinahanglan - ug mahimo - masulbad. Kung nagtukod ka usa ka serbisyo, tan-awa kini gikan sa taas, tan-awa ang tanan nga mga peligro nga mahimong mahitabo. Kung makita nimo sila dayon, nan paghatag alang sa redundancy nga abante ug ang posibilidad sa pagtukod sa usa ka fault-tolerant nga imprastraktura, tungod kay ang bisan unsang punto nga mahimong mapakyas ug mosangpot sa pagka-inoperability sa serbisyo siguradong buhaton kini. Ug bisan kung ingon kanimo nga ang pipila ka mga elemento sa imprastraktura siguradong dili mapakyas - sama sa s3, hinumdomi gihapon nga mahimo nila. At least sa theory, naay idea kung unsa imong buhaton nila kung naay mahitabo. Adunay plano sa pagdumala sa peligro. Kung naghunahuna ka bahin sa pagbuhat sa tanan nga awtomatiko o mano-mano, susihon ang mga peligro: unsa ang mahitabo kung ang automation magsugod sa pagbalhin sa tanan - dili ba kini mosangput sa usa ka labi ka grabe nga kahimtang kung itandi sa usa ka aksidente? Tingali sa usa ka dapit kinahanglan nga gamiton ang usa ka makatarunganon nga pagkompromiso tali sa paggamit sa automation ug sa reaksyon sa engineer nga nag-duty, kinsa mag-evaluate sa tinuod nga hulagway ug makasabut kung adunay kinahanglan nga ibalhin sa lugar o "oo, apan dili karon."
Usa ka makatarunganon nga pagkompromiso tali sa pagkamahingpiton ug tinuod nga paningkamot, oras, salapi nga mahimo nimong gastohon sa laraw nga sa katapusan maangkon nimo.
Kini nga teksto usa ka updated ug gipalapdan nga bersyon sa report ni Alexander Demidov sa komperensya .
Source: www.habr.com