Hello, Habr! Ako si Artem Karamyshev, pinuno ng system administration team . Nagkaroon kami ng maraming bagong paglulunsad ng produkto sa nakalipas na taon. Nais naming tiyakin na ang mga serbisyo ng API ay madaling masusukat, mapagparaya, at handa para sa mabilis na paglaki ng pag-load ng user. Ang aming platform ay ipinatupad sa OpenStack, at gusto kong sabihin sa iyo kung anong bahagi ang mga problema sa pagpapaubaya ng kasalanan na kailangan naming lutasin upang makakuha ng sistemang hindi mapagparaya sa pagkakamali. Sa tingin ko ito ay magiging kawili-wili para sa mga gumagawa din ng mga produkto sa OpenStack.
Ang pangkalahatang fault tolerance ng isang platform ay binubuo ng katatagan ng mga bahagi nito. Kaya unti-unti nating dadaan ang lahat ng antas kung saan natukoy natin ang mga panganib at isinara ang mga ito.
Bersyon ng video ng kuwentong ito, ang pangunahing pinagmulan nito ay isang ulat sa Uptime day 4 conference, na inayos ni , nakikita mo .
Katatagan ng pisikal na arkitektura
Ang pampublikong bahagi ng MCS cloud ay nakabatay na ngayon sa dalawang Tier III data center, sa pagitan ng mga ito ay mayroong sarili nitong dark fiber, na nakalaan sa pisikal na antas ng iba't ibang ruta, na may throughput na 200 Gbit/s. Ang Tier III ay nagbibigay ng kinakailangang antas ng fault tolerance para sa pisikal na imprastraktura.
Ang madilim na hibla ay nakalaan sa parehong pisikal at lohikal na antas. Ang proseso ng pagpapareserba ng channel ay umuulit, lumitaw ang mga problema, at patuloy naming pinapabuti ang komunikasyon sa pagitan ng mga data center.
Halimbawa, hindi pa matagal na ang nakalipas, habang nagtatrabaho sa isang balon malapit sa isa sa mga sentro ng data, sinira ng isang excavator ang isang tubo, at sa loob ng tubo na ito ay may parehong pangunahing at isang backup na optical cable. Ang aming fault-tolerant na channel ng komunikasyon sa data center ay naging mahina sa isang punto, sa balon. Alinsunod dito, nawalan tayo ng bahagi ng imprastraktura. Gumawa kami ng mga konklusyon at gumawa ng ilang mga aksyon, kabilang ang pag-install ng karagdagang mga optika sa katabing balon.
Sa mga data center ay may mga punto ng presensya ng mga nagbibigay ng komunikasyon kung saan namin i-broadcast ang aming mga prefix sa pamamagitan ng BGP. Para sa bawat direksyon ng network, pinipili ang pinakamahusay na sukatan, na nagbibigay-daan sa iba't ibang kliyente na mabigyan ng pinakamahusay na kalidad ng koneksyon. Kung ang komunikasyon sa pamamagitan ng isang provider ay bumaba, muli naming ibubuo ang aming pagruruta sa pamamagitan ng mga available na provider.
Kung nabigo ang isang provider, awtomatiko kaming lumipat sa susunod. Kung sakaling mabigo ang isa sa mga data center, mayroon kaming mirror copy ng aming mga serbisyo sa pangalawang data center, na kumukuha sa buong pag-load.
Katatagan ng pisikal na imprastraktura
Ano ang ginagamit namin para sa application-level fault tolerance
Ang aming serbisyo ay binuo sa isang bilang ng mga bahagi ng opensource.
ExaBGP ay isang serbisyo na nagpapatupad ng ilang function gamit ang BGP-based dynamic routing protocol. Aktibong ginagamit namin ito upang i-advertise ang aming mga naka-whitelist na IP address kung saan ina-access ng mga user ang API.
HAProxy ay isang high-load balancer na nagbibigay-daan sa iyong i-configure ang napaka-flexible na mga panuntunan sa pagbabalanse ng trapiko sa iba't ibang antas ng modelo ng OSI. Ginagamit namin ito upang balansehin sa harap ng lahat ng mga serbisyo: mga database, mga broker ng mensahe, mga serbisyo ng API, mga serbisyo sa web, aming mga panloob na proyekto - lahat ay nasa likod ng HAProxy.
Application ng API — isang web application na nakasulat sa python, kung saan pinamamahalaan ng user ang kanyang imprastraktura at ang kanyang serbisyo.
Aplikasyon ng manggagawa (simula dito ay simpleng manggagawa) - sa mga serbisyo ng OpenStack, ito ay isang daemon ng imprastraktura na nagbibigay-daan sa iyong mag-broadcast ng mga utos ng API sa imprastraktura. Halimbawa, ang paggawa ng disk ay nangyayari sa manggagawa, at ang kahilingan sa paglikha ay nangyayari sa application API.
Karaniwang Arkitektura ng Application ng OpenStack
Karamihan sa mga serbisyo na binuo para sa OpenStack ay sumusubok na sumunod sa isang solong paradigm. Karaniwang binubuo ang isang serbisyo ng 2 bahagi: API at mga manggagawa (mga backend executor). Bilang isang patakaran, ang isang API ay isang WSGI application sa python, na inilunsad bilang isang independiyenteng proseso (daemon), o gamit ang isang yari na Nginx o Apache web server. Pinoproseso ng API ang kahilingan ng user at ipinapasa ang mga karagdagang tagubilin sa application ng manggagawa para sa pagpapatupad. Nagaganap ang paglipat gamit ang isang broker ng mensahe, kadalasan ang RabbitMQ, ang iba ay hindi gaanong suportado. Kapag nakarating ang mga mensahe sa broker, pinoproseso ang mga ito ng mga manggagawa at, kung kinakailangan, magbabalik ng tugon.
Ang paradigm na ito ay nagsasangkot ng mga nakahiwalay na karaniwang mga punto ng kabiguan: RabbitMQ at ang database. Ngunit ang RabbitMQ ay nakahiwalay sa loob ng isang serbisyo at, sa teorya, ay maaaring indibidwal para sa bawat serbisyo. Kaya't sa MCS ay pinaghihiwalay namin ang mga serbisyong ito hangga't maaari; para sa bawat indibidwal na proyekto ay gumagawa kami ng hiwalay na database, isang hiwalay na RabbitMQ. Ang diskarte na ito ay mabuti dahil sa kaganapan ng isang aksidente sa ilang mga bulnerable na punto, hindi ang buong serbisyo ay masira, ngunit bahagi lamang nito.
Ang bilang ng mga application ng manggagawa ay walang limitasyon, kaya ang API ay madaling masukat nang pahalang sa likod ng mga balancer upang mapataas ang performance at fault tolerance.
Ang ilang mga serbisyo ay nangangailangan ng koordinasyon sa loob ng serbisyo kapag ang mga kumplikadong sunud-sunod na operasyon ay nagaganap sa pagitan ng mga API at mga manggagawa. Sa kasong ito, ginagamit ang isang solong coordination center, isang cluster system tulad ng Redis, Memcache, etcd, na nagbibigay-daan sa isang manggagawa na sabihin sa isa pa na ang gawaing ito ay itinalaga sa kanya ("mangyaring huwag kunin ito"). Ginagamit namin etcd. Bilang isang patakaran, ang mga manggagawa ay aktibong nakikipag-usap sa database, sumulat at nagbabasa ng impormasyon mula doon. Ginagamit namin ang mariadb bilang isang database, na matatagpuan sa isang multimaster cluster.
Ang klasikong solong serbisyong ito ay nakaayos sa paraang karaniwang tinatanggap para sa OpenStack. Maaari itong ituring bilang isang saradong sistema, kung saan ang mga pamamaraan ng scaling at fault tolerance ay medyo halata. Halimbawa, para sa API fault tolerance, sapat na maglagay ng balancer sa harap nila. Ang pag-scale ng mga manggagawa ay nakakamit sa pamamagitan ng pagtaas ng kanilang bilang.
Ang mahinang punto sa buong scheme ay RabbitMQ at MariaDB. Ang kanilang arkitektura ay nararapat sa isang hiwalay na artikulo. Sa artikulong ito gusto kong tumuon sa API fault tolerance.
Arkitektura ng Application ng Openstack. Pagbabalanse at fault tolerance ng cloud platform
Ginagawa ang HAProxy balancer fault-tolerant gamit ang ExaBGP
Para gawing scalable, mabilis, at fault-tolerant ang aming mga API, naglalagay kami ng load balancer sa harap ng mga ito. Pinili namin ang HAProxy. Sa aking opinyon, mayroon itong lahat ng kinakailangang katangian para sa aming gawain: pagbabalanse sa ilang mga antas ng OSI, isang interface ng pamamahala, flexibility at scalability, isang malaking bilang ng mga paraan ng pagbabalanse, suporta para sa mga talahanayan ng session.
Ang unang problema na kailangang malutas ay ang fault tolerance ng balancer mismo. Ang simpleng pag-install ng balancer ay lumilikha din ng isang punto ng pagkabigo: ang balancer ay masira at ang serbisyo ay nag-crash. Upang maiwasang mangyari ito, ginamit namin ang HAProxy kasabay ng ExaBGP.
Binibigyang-daan ka ng ExaBGP na magpatupad ng mekanismo para sa pagsuri sa estado ng isang serbisyo. Ginamit namin ang mekanismong ito upang suriin ang paggana ng HAProxy at, kung sakaling magkaroon ng mga problema, huwag paganahin ang serbisyo ng HAProxy mula sa BGP.
ExaBGP+HAProxy scheme
- Ini-install namin ang kinakailangang software, ExaBGP at HAProxy, sa tatlong server.
- Lumilikha kami ng loopback interface sa bawat server.
- Sa lahat ng tatlong server ay nagtatalaga kami ng parehong puting IP address sa interface na ito.
- Ang isang puting IP address ay ina-advertise sa Internet sa pamamagitan ng ExaBGP.
Nakakamit ang fault tolerance sa pamamagitan ng pag-advertise ng parehong IP address mula sa lahat ng tatlong server. Mula sa isang network point of view, ang parehong address ay naa-access mula sa tatlong magkakaibang susunod na hops. Nakikita ng router ang tatlong magkakahawig na ruta, pinipili ang pinakamataas na priyoridad ng mga ito batay sa sarili nitong sukatan (karaniwang ito ang parehong opsyon), at ang trapiko ay napupunta lamang sa isa sa mga server.
Sa kaso ng mga problema sa pagpapatakbo ng HAProxy o pagkabigo ng server, hihinto ang ExaBGP sa pag-anunsyo ng ruta, at ang trapiko ay maayos na lumipat sa ibang server.
Kaya, nakamit namin ang fault tolerance ng balancer.
Fault tolerance ng HAProxy balancers
Ang scheme ay naging hindi perpekto: natutunan namin kung paano magreserba ng HAProxy, ngunit hindi natutunan kung paano ipamahagi ang load sa loob ng mga serbisyo. Samakatuwid, pinalawak namin nang kaunti ang scheme na ito: lumipat kami sa pagbabalanse sa pagitan ng ilang puting IP address.
Pagbabalanse batay sa DNS plus BGP
Ang isyu ng load balancing para sa aming HAProxy ay nananatiling hindi nareresolba. Gayunpaman, maaari itong malutas nang simple, tulad ng ginawa namin dito.
Para balansehin ang tatlong server kakailanganin mo ng 3 puting IP address at magandang lumang DNS. Ang bawat isa sa mga address na ito ay tinutukoy sa loopback interface ng bawat HAProxy at ina-advertise sa Internet.
Sa OpenStack, upang pamahalaan ang mga mapagkukunan, isang direktoryo ng serbisyo ang ginagamit, na tumutukoy sa endpoint API ng isang partikular na serbisyo. Sa direktoryong ito ay nagrerehistro kami ng isang domain name - public.infra.mail.ru, na nalutas sa pamamagitan ng DNS ng tatlong magkakaibang mga IP address. Bilang resulta, nakakakuha kami ng pamamahagi ng pagkarga sa pagitan ng tatlong address sa pamamagitan ng DNS.
Ngunit dahil kapag nag-aanunsyo ng mga puting IP address ay hindi namin kinokontrol ang mga priyoridad sa pagpili ng server, hindi pa ito nagbabalanse. Karaniwan, isang server lang ang pipiliin batay sa katandaan ng IP address, at ang dalawa pa ay magiging idle dahil walang mga sukatan na tinukoy sa BGP.
Nagsimula kaming magpadala ng mga ruta sa pamamagitan ng ExaBGP na may iba't ibang sukatan. Ang bawat balancer ay nag-a-advertise ng lahat ng tatlong puting IP address, ngunit isa sa mga ito, ang pangunahing isa para sa balancer na ito, ay ina-advertise na may pinakamababang sukatan. Kaya habang gumagana ang lahat ng tatlong balancer, ang mga tawag sa unang IP address ay mapupunta sa unang balancer, tumatawag sa pangalawa hanggang sa pangalawa, at tawag sa ikatlo hanggang sa pangatlo.
Ano ang mangyayari kapag nahulog ang isa sa mga balancer? Kung nabigo ang anumang balancer, ang pangunahing address nito ay ina-advertise pa rin mula sa iba pang dalawa, at muling ipapamahagi ang trapiko sa pagitan nila. Kaya, binibigyan namin ang user ng ilang IP address nang sabay-sabay sa pamamagitan ng DNS. Sa pamamagitan ng pagbabalanse sa pamamagitan ng DNS at iba't ibang sukatan, nakakakuha kami ng pantay na pamamahagi ng load sa lahat ng tatlong tagabalanse. At kasabay nito, hindi tayo nawawalan ng pagpapaubaya sa kasalanan.
Pagbabalanse ng HAProxy batay sa DNS + BGP
Pakikipag-ugnayan sa pagitan ng ExaBGP at HAProxy
Kaya, nagpatupad kami ng fault tolerance kung sakaling umalis ang server, batay sa pagpapahinto sa anunsyo ng mga ruta. Ngunit ang HAProxy ay maaaring mag-shut down para sa iba pang mga kadahilanan kaysa sa pagkabigo ng server: mga error sa pangangasiwa, mga pagkabigo sa loob ng serbisyo. Gusto naming alisin ang sirang balancer mula sa ilalim ng load sa mga kasong ito, at kailangan namin ng ibang mekanismo.
Samakatuwid, sa pagpapalawak ng nakaraang scheme, ipinatupad namin ang heartbeat sa pagitan ng ExaBGP at HAProxy. Ito ay isang pagpapatupad ng software ng pakikipag-ugnayan sa pagitan ng ExaBGP at HAProxy, kapag gumagamit ang ExaBGP ng mga custom na script upang suriin ang katayuan ng mga application.
Upang gawin ito, kailangan mong i-configure ang isang health checker sa ExaBGP config, na maaaring suriin ang katayuan ng HAProxy. Sa aming kaso, na-configure namin ang backend ng kalusugan sa HAProxy, at mula sa panig ng ExaBGP, sinusuri namin ang isang simpleng kahilingan sa GET. Kung huminto ang anunsyo, malamang na hindi gumagana ang HAProxy at hindi na kailangang i-advertise ito.
HAProxy Health Check
HAProxy Peers: pag-synchronize ng session
Ang susunod na gagawin ay ang pag-synchronize ng mga session. Kapag nagtatrabaho sa pamamagitan ng mga distributed balancer, mahirap ayusin ang pag-iimbak ng impormasyon tungkol sa mga session ng kliyente. Ngunit ang HAProxy ay isa sa ilang mga balancer na makakagawa nito dahil sa functionality ng Peers - ang kakayahang maglipat ng mga talahanayan ng session sa pagitan ng iba't ibang proseso ng HAProxy.
Mayroong iba't ibang paraan ng pagbabalanse: mga simple tulad ng , at pinalawig, kapag naaalala ang session ng kliyente, at sa bawat oras na mapupunta siya sa parehong server tulad ng dati. Nais naming ipatupad ang pangalawang opsyon.
Gumagamit ang HAProxy ng mga stick-table para i-save ang mga session ng kliyente ng mekanismong ito. Ise-save nila ang orihinal na IP address ng kliyente, ang napiling target na address (backend) at ilang impormasyon ng serbisyo. Karaniwan, ang mga stick table ay ginagamit upang mag-imbak ng source-IP + destination-IP na pares, na partikular na kapaki-pakinabang para sa mga application na hindi makapaglipat ng konteksto ng session ng user kapag lumipat sa ibang balancer, halimbawa, sa RoundRobin balancing mode.
Kung ang isang stick table ay tinuturuan na lumipat sa pagitan ng iba't ibang mga proseso ng HAProxy (sa pagitan ng kung saan ang pagbabalanse ay nangyayari), ang aming mga balancer ay makakapagtrabaho sa isang pool ng mga stick table. Gagawin nitong posible na walang putol na lumipat sa network ng kliyente kung nabigo ang isa sa mga balancer; magpapatuloy ang pakikipagtulungan sa mga session ng kliyente sa parehong mga backend na napili nang mas maaga.
Para sa wastong operasyon, ang problema ng source IP address ng balancer kung saan itinatag ang session ay dapat malutas. Sa aming kaso, ito ay isang dynamic na address sa loopback interface.
Ang tamang gawain ng mga kapantay ay nakakamit lamang sa ilalim ng ilang mga kundisyon. Ibig sabihin, dapat sapat na malaki ang mga timeout ng TCP o dapat sapat na mabilis ang paglipat upang ang session ng TCP ay walang oras upang wakasan. Gayunpaman, pinapayagan nito ang tuluy-tuloy na paglipat.
Sa IaaS mayroon kaming ginawang serbisyo gamit ang parehong teknolohiya. Ito , na tinatawag na Octavia. Ito ay batay sa dalawang proseso ng HAProxy at sa una ay may kasamang suporta para sa mga kapantay. Napatunayan nila ang kanilang sarili na mahusay sa serbisyong ito.
Ang larawan ay schematically na nagpapakita ng paggalaw ng mga peer table sa pagitan ng tatlong HAProxy instance, isang config ang iminungkahi kung paano ito mako-configure:
HAProxy Peers (pag-synchronize ng session)
Kung ipapatupad mo ang parehong pamamaraan, ang operasyon nito ay dapat na maingat na masuri. Ito ay hindi isang katotohanan na ito ay gagana sa parehong paraan 100% ng oras. Ngunit hindi bababa sa hindi mawawala ang mga talahanayan ng stick kapag kailangan mong tandaan ang pinagmulan ng IP ng kliyente.
Nililimitahan ang bilang ng mga sabay-sabay na kahilingan mula sa parehong kliyente
Anumang mga serbisyo na available sa publiko, kabilang ang aming mga API, ay maaaring sumailalim sa mga pag-avalanch ng mga kahilingan. Ang mga dahilan para sa mga ito ay maaaring ganap na naiiba, mula sa mga error ng user hanggang sa mga naka-target na pag-atake. Pana-panahon kaming DDoSed ng mga IP address. Madalas nagkakamali ang mga kliyente sa kanilang mga script at binibigyan kami ng mga mini-DDoS.
Sa isang paraan o iba pa, kailangang magbigay ng karagdagang proteksyon. Ang malinaw na solusyon ay upang limitahan ang bilang ng mga kahilingan sa API at hindi mag-aksaya ng oras ng CPU sa pagproseso ng mga nakakahamak na kahilingan.
Upang ipatupad ang mga naturang paghihigpit, gumagamit kami ng mga limitasyon sa rate, na nakaayos batay sa HAProxy, gamit ang parehong mga talahanayan ng stick. Ang pag-set up ng mga limitasyon ay medyo simple at nagbibigay-daan sa iyong limitahan ang user sa bilang ng mga kahilingan sa API. Naaalala ng algorithm ang pinagmulang IP kung saan ginawa ang mga kahilingan at nililimitahan ang bilang ng mga sabay-sabay na kahilingan mula sa isang user. Siyempre, kinakalkula namin ang average na profile ng pag-load ng API para sa bawat serbisyo at nagtakda ng limitasyon na ≈ 10 beses sa halagang ito. Patuloy naming sinusubaybayan nang mabuti ang sitwasyon at pinapanatili ang aming daliri sa pulso.
Ano ang hitsura nito sa pagsasanay? Mayroon kaming mga customer na gumagamit ng aming mga autoscaling API sa lahat ng oras. Lumilikha sila ng humigit-kumulang dalawa hanggang tatlong daang virtual machine sa umaga at tinatanggal ang mga ito sa gabi. Para sa OpenStack, ang paglikha ng isang virtual machine, kasama rin ang mga serbisyo ng PaaS, ay nangangailangan ng hindi bababa sa 1000 mga kahilingan sa API, dahil ang pakikipag-ugnayan sa pagitan ng mga serbisyo ay nangyayari rin sa pamamagitan ng API.
Ang ganitong paglipat ng mga gawain ay nagdudulot ng medyo malaking pagkarga. Sinuri namin ang load na ito, nakolekta ang mga pang-araw-araw na peak, pinataas ang mga ito ng sampung beses, at ito ang naging limitasyon namin sa rate. Pinapanatili namin ang aming daliri sa pulso. Madalas kaming makakita ng mga bot at scanner na sumusubok na tumingin sa amin upang makita kung mayroon kaming anumang mga CGA script na maaaring patakbuhin, aktibong pinuputol namin ang mga ito.
Paano i-update ang iyong codebase nang hindi napapansin ng mga user
Nagpapatupad din kami ng fault tolerance sa antas ng mga proseso ng pag-deploy ng code. Maaaring may mga glitches sa panahon ng mga rollout, ngunit ang epekto nito sa availability ng serbisyo ay maaaring mabawasan.
Patuloy naming ina-update ang aming mga serbisyo at dapat na tiyaking na-update ang codebase nang hindi naaapektuhan ang mga user. Nagawa naming lutasin ang problemang ito gamit ang mga kakayahan sa pamamahala ng HAProxy at ang pagpapatupad ng Graceful Shutdown sa aming mga serbisyo.
Upang malutas ang problemang ito, kinakailangan upang matiyak ang kontrol ng balancer at ang "tama" na pagsasara ng mga serbisyo:
- Sa kaso ng HAProxy, ang kontrol ay ginagawa sa pamamagitan ng stats file, na mahalagang isang socket at tinukoy sa HAProxy config. Maaari kang magpadala ng mga utos dito sa pamamagitan ng stdio. Ngunit ang aming pangunahing tool sa pagkontrol sa pagsasaayos ay magagawa, kaya mayroon itong built-in na module para sa pamamahala ng HAProxy. Na aktibong ginagamit namin.
- Karamihan sa aming mga serbisyo ng API at Engine ay sumusuporta sa magagandang teknolohiya sa pagsasara: kapag nagsasara, hinihintay nilang makumpleto ang kasalukuyang gawain, ito man ay isang kahilingan sa http o ilang gawain sa serbisyo. Ganoon din ang nangyayari sa manggagawa. Alam nito ang lahat ng mga gawain na ginagawa nito at nagtatapos kapag matagumpay nitong natapos ang lahat.
Salamat sa dalawang puntong ito, ganito ang hitsura ng ligtas na algorithm para sa aming deployment.
- Nag-assemble ang developer ng bagong package ng code (para sa amin ito ay RPM), sinusubok ito sa dev environment, sinusubok ito sa stage, at iniiwan ito sa stage repository.
- Itinakda ng developer ang gawain para sa pag-deploy gamit ang pinakadetalyadong paglalarawan ng "mga artifact": ang bersyon ng bagong package, isang paglalarawan ng bagong functionality at iba pang mga detalye tungkol sa deployment kung kinakailangan.
- Sinisimulan ng system administrator ang pag-update. Inilunsad ang Ansible playbook, na ginagawa naman ang sumusunod:
- Kumuha ng package mula sa stage repository at ginagamit ito para i-update ang bersyon ng package sa product repository.
- Nag-compile ng listahan ng mga backend ng na-update na serbisyo.
- Isinasara ang unang serbisyong maa-update sa HAProxy at hintaying matapos ang mga proseso nito. Salamat sa magandang pagsasara, tiwala kami na matagumpay na makukumpleto ang lahat ng kasalukuyang kahilingan ng kliyente.
- Matapos ganap na ihinto ang API at mga manggagawa, at i-off ang HAProxy, ina-update ang code.
- Ang Ansible ay nagpapatakbo ng mga serbisyo.
- Para sa bawat serbisyo, hinihila ang ilang partikular na "mga handle", na nagsasagawa ng unit testing sa ilang mga paunang natukoy na key test. Ang isang pangunahing pagsusuri ng bagong code ay nagaganap.
- Kung walang nakitang mga error sa nakaraang hakbang, ang backend ay isinaaktibo.
- Lumipat tayo sa susunod na backend.
- Pagkatapos ma-update ang lahat ng backend, inilulunsad ang mga functional na pagsubok. Kung nawawala ang mga ito, titingnan ng developer ang anumang bagong functionality na ginawa niya.
Kinukumpleto nito ang pag-deploy.
Ikot ng pag-update ng serbisyo
Hindi gagana ang scheme na ito kung wala tayong isang panuntunan. Sinusuportahan namin pareho ang luma at bagong bersyon sa labanan. Sa maaga, sa yugto ng pag-unlad ng software, inilatag na kahit na may mga pagbabago sa database ng serbisyo, hindi nila masisira ang nakaraang code. Bilang resulta, unti-unting ina-update ang code base.
Konklusyon
Ibinabahagi ang aking sariling mga saloobin tungkol sa isang fault-tolerant na arkitektura ng WEB, nais kong muling tandaan ang mga pangunahing punto nito:
- pisikal na pagpapahintulot sa kasalanan;
- network fault tolerance (balancers, BGP);
- fault tolerance ng software na ginamit at binuo.
Stable uptime sa lahat!
Pinagmulan: www.habr.com
