Ito ay isang pagpapatuloy ng isang mahabang kuwento tungkol sa aming mahirap na landas sa paglikha ng isang malakas, mataas na load system na nagsisiguro sa pagpapatakbo ng Exchange. Narito ang unang bahagi:
Mahiwagang pagkakamali
Pagkatapos ng maraming pagsubok, ang na-update na trading at clearing system ay inilagay sa operasyon, at nakatagpo kami ng isang bug kung saan maaari kaming sumulat ng isang detective-mystical na kuwento.
Di-nagtagal pagkatapos ilunsad sa pangunahing server, ang isa sa mga transaksyon ay naproseso nang may error. Gayunpaman, maayos ang lahat sa backup server. Ito ay naka-out na ang isang simpleng mathematical na operasyon ng pagkalkula ng exponent sa pangunahing server ay nagbigay ng negatibong resulta mula sa tunay na argumento! Ipinagpatuloy namin ang aming pananaliksik, at sa rehistro ng SSE2 nakita namin ang isang pagkakaiba sa isang bit, na responsable para sa pag-ikot kapag nagtatrabaho sa mga numero ng floating point.
Sumulat kami ng isang simpleng test utility para kalkulahin ang exponent na may rounding bit set. Ito ay lumabas na sa bersyon ng RedHat Linux na ginamit namin, mayroong isang bug sa pagtatrabaho sa mathematical function kapag ipinasok ang masamang bit. Iniulat namin ito sa RedHat, pagkaraan ng ilang sandali ay nakatanggap kami ng isang patch mula sa kanila at inilunsad ito. Hindi na naganap ang error, ngunit hindi malinaw kung saan nanggaling ang bit na ito? Ang function ay responsable para dito fesetround mula sa wikang C. Maingat naming sinuri ang aming code sa paghahanap ng dapat na error: sinuri namin ang lahat ng posibleng sitwasyon; tumingin sa lahat ng mga function na ginamit rounding; sinubukang magparami ng nabigong session; gumamit ng iba't ibang mga compiler na may iba't ibang mga pagpipilian; Ginamit ang static at dynamic na pagsusuri.
Hindi mahanap ang sanhi ng error.
Pagkatapos ay sinimulan nilang suriin ang hardware: nagsagawa sila ng pagsubok sa pag-load ng mga processor; sinuri ang RAM; Nagpatakbo pa kami ng mga pagsubok para sa hindi malamang na senaryo ng isang multi-bit na error sa isang cell. Upang hindi mapakinabangan.
Sa huli, kami ay nanirahan sa isang teorya mula sa mundo ng high-energy physics: ilang high-energy particle ang lumipad papunta sa aming data center, tumusok sa case wall, tumama sa processor at naging sanhi ng pagdikit ng trigger latch sa mismong bit na iyon. Ang walang katotohanan na teoryang ito ay tinawag na "neutrino." Kung ikaw ay malayo sa particle physics: ang mga neutrino ay halos hindi nakikipag-ugnayan sa labas ng mundo, at tiyak na hindi makakaapekto sa pagpapatakbo ng processor.
Dahil hindi posible na mahanap ang sanhi ng pagkabigo, ang "nakakasakit" na server ay inalis mula sa operasyon kung sakali.
Pagkaraan ng ilang oras, sinimulan naming pagbutihin ang mainit na backup system: ipinakilala namin ang tinatawag na "warm reserves" (warm) - asynchronous replicas. Nakatanggap sila ng stream ng mga transaksyon na maaaring matatagpuan sa iba't ibang data center, ngunit hindi aktibong nakikipag-ugnayan ang warms sa ibang mga server.
Bakit ito ginawa? Kung nabigo ang backup server, ang mainit na nakatali sa pangunahing server ang magiging bagong backup. Iyon ay, pagkatapos ng isang pagkabigo, ang sistema ay hindi mananatili sa isang pangunahing server hanggang sa katapusan ng sesyon ng kalakalan.
At nang ang bagong bersyon ng system ay sinubukan at inilagay sa operasyon, ang rounding bit error ay naganap muli. Bukod dito, sa pagtaas ng bilang ng mga mainit na server, ang error ay nagsimulang lumitaw nang mas madalas. Kasabay nito, ang vendor ay walang maipakita, dahil walang konkretong ebidensya.
Sa susunod na pagsusuri ng sitwasyon, lumitaw ang isang teorya na ang problema ay maaaring nauugnay sa OS. Sumulat kami ng isang simpleng programa na tumatawag sa isang function sa isang walang katapusang loop fesetround, naaalala ang kasalukuyang estado at sinusuri ito sa pamamagitan ng pagtulog, at ginagawa ito sa maraming nakikipagkumpitensyang mga thread. Ang pagkakaroon ng napiling mga parameter para sa pagtulog at ang bilang ng mga thread, sinimulan naming patuloy na kopyahin ang bit failure pagkatapos ng halos 5 minuto ng pagpapatakbo ng utility. Gayunpaman, hindi ito nagawang kopyahin ng suporta ng Red Hat. Ang pagsubok sa aming iba pang mga server ay nagpakita na ang mga may ilang partikular na processor lamang ang madaling kapitan sa error. Kasabay nito, ang paglipat sa isang bagong kernel ay nalutas ang problema. Sa huli, pinalitan lang namin ang OS, at ang tunay na sanhi ng bug ay nanatiling hindi malinaw.
At biglang noong nakaraang taon isang artikulo ang nai-publish sa HabrΓ© "" Ang sitwasyong inilarawan dito ay halos kapareho sa atin, ngunit ang may-akda ay nagsagawa ng karagdagang pagsisiyasat at naglagay ng isang teorya na ang pagkakamali ay nasa microcode. At kapag na-update ang mga kernel ng Linux, ina-update din ng mga tagagawa ang microcode.
Karagdagang pag-unlad ng sistema
Bagama't inalis namin ang error, pinilit kami ng kuwentong ito na muling isaalang-alang ang arkitektura ng system. Pagkatapos ng lahat, hindi kami protektado mula sa pag-uulit ng gayong mga bug.
Ang mga sumusunod na prinsipyo ay naging batayan para sa mga susunod na pagpapabuti sa sistema ng reserbasyon:
- Hindi mo mapagkakatiwalaan ang sinuman. Maaaring hindi gumana nang maayos ang mga server.
- Pagpapareserba ng karamihan.
- Pagtitiyak ng pinagkasunduan. Bilang lohikal na karagdagan sa reserbasyon ng karamihan.
- Posible ang dobleng pagkabigo.
- Kasiglahan. Ang bagong hot standby scheme ay hindi dapat mas masama kaysa sa nauna. Ang pangangalakal ay dapat magpatuloy nang walang patid hanggang sa huling server.
- Bahagyang pagtaas ng latency. Ang anumang downtime ay nangangailangan ng malaking pagkalugi sa pananalapi.
- Minimal na pakikipag-ugnayan sa network upang panatilihing mababa ang latency hangga't maaari.
- Pagpili ng bagong master server sa ilang segundo.
Wala sa mga solusyon na magagamit sa merkado ang nababagay sa amin, at ang Raft protocol ay nasa simula pa lamang, kaya gumawa kami ng sarili naming solusyon.
Networking
Bilang karagdagan sa sistema ng pagpapareserba, sinimulan naming gawing moderno ang pakikipag-ugnayan sa network. Ang I/O subsystem ay binubuo ng maraming proseso, na may pinakamasamang epekto sa jitter at latency. Sa daan-daang prosesong humahawak sa mga koneksyon sa TCP, napilitan kaming patuloy na magpalipat-lipat sa pagitan ng mga ito, at sa isang microsecond scale ito ay medyo matagal na operasyon. Ngunit ang pinakamasamang bahagi ay kapag ang isang proseso ay nakatanggap ng isang packet para sa pagproseso, ipinadala ito sa isang SystemV queue at pagkatapos ay naghintay para sa isang kaganapan mula sa isa pang SystemV queue. Gayunpaman, kapag mayroong isang malaking bilang ng mga node, ang pagdating ng isang bagong TCP packet sa isang proseso at ang pagtanggap ng data sa queue sa isa pa ay kumakatawan sa dalawang nakikipagkumpitensyang kaganapan para sa OS. Sa kasong ito, kung walang mga pisikal na processor na magagamit para sa parehong mga gawain, ang isa ay ipoproseso, at ang pangalawa ay ilalagay sa isang naghihintay na pila. Imposibleng hulaan ang mga kahihinatnan.
Sa ganitong mga sitwasyon, maaaring gamitin ang dynamic na proseso ng priority control, ngunit kakailanganin nito ang paggamit ng mga resource-intensive system call. Bilang resulta, lumipat kami sa isang thread gamit ang classic na epoll, lubos nitong pinataas ang bilis at nabawasan ang oras ng pagproseso ng transaksyon. Inalis din namin ang magkahiwalay na proseso ng komunikasyon sa network at komunikasyon sa pamamagitan ng SystemV, makabuluhang nabawasan ang bilang ng mga tawag sa system at nagsimulang kontrolin ang mga priyoridad ng mga operasyon. Sa subsystem ng I/O lamang, posibleng makatipid ng mga 8-17 microsecond, depende sa senaryo. Ang single-threaded scheme na ito ay ginamit nang hindi nabago mula noon; sapat na ang isang epoll thread na may margin para serbisyo sa lahat ng koneksyon.
Pagproseso ng Transaksyon
Ang lumalaking load sa aming system ay nangangailangan ng pag-upgrade sa halos lahat ng mga bahagi nito. Ngunit, sa kasamaang-palad, ang pagwawalang-kilos sa paglago ng mga bilis ng orasan ng processor sa mga nakaraang taon ay hindi na naging posible upang masukat ang mga proseso nang direkta. Samakatuwid, nagpasya kaming hatiin ang proseso ng Engine sa tatlong antas, kung saan ang pinaka-abala sa mga ito ay ang sistema ng pagsusuri sa peligro, na sinusuri ang pagkakaroon ng mga pondo sa mga account at gagawa ng mga transaksyon mismo. Ngunit ang pera ay maaaring nasa iba't ibang mga pera, at kinakailangan upang malaman kung anong batayan ang pagpoproseso ng mga kahilingan ay dapat hatiin.
Ang lohikal na solusyon ay upang hatiin ito sa pamamagitan ng pera: ang isang server ay nakikipagkalakalan sa dolyar, isa pa sa pounds, at isang pangatlo sa euro. Ngunit kung, sa gayong pamamaraan, dalawang transaksyon ang ipinadala upang bumili ng iba't ibang mga pera, kung gayon ang problema ng desynchronization ng wallet ay lilitaw. Ngunit ang pag-synchronize ay mahirap at mahal. Samakatuwid, magiging tama ang paghiwa-hiwalay ng mga wallet at paghiwalayin ng mga instrumento. Sa pamamagitan ng paraan, ang karamihan sa mga palitan ng Kanluran ay walang gawain na suriin ang mga panganib na kasing acute ng ginagawa namin, kaya kadalasan ito ay ginagawa offline. Kailangan naming ipatupad ang online na pag-verify.
Ipaliwanag natin sa isang halimbawa. Gustong bumili ng isang negosyante ng $30, at ang kahilingan ay mapupunta sa pagpapatunay ng transaksyon: sinusuri namin kung pinapayagan ang trader na ito sa trading mode na ito at kung mayroon siyang mga kinakailangang karapatan. Kung maayos ang lahat, mapupunta ang kahilingan sa sistema ng pag-verify ng panganib, i.e. upang suriin ang kasapatan ng mga pondo upang tapusin ang isang transaksyon. May tala na kasalukuyang naka-block ang kinakailangang halaga. Ang kahilingan ay ipapasa sa sistema ng pangangalakal, na aprubahan o hindi aprubahan ang transaksyon. Sabihin nating naaprubahan ang transaksyon - pagkatapos ay minarkahan ng sistema ng pag-verify ng panganib na ang pera ay na-unblock, at ang mga rubles ay nagiging dolyar.
Sa pangkalahatan, ang sistema ng pagsusuri sa peligro ay naglalaman ng mga kumplikadong algorithm at nagsasagawa ng isang malaking halaga ng mga kalkulasyon na napakalakas ng mapagkukunan, at hindi lamang sinusuri ang "balanse ng account", na tila sa unang tingin.
Noong sinimulan naming hatiin ang proseso ng Engine sa mga antas, nakatagpo kami ng problema: ang code na available noong panahong iyon ay aktibong gumamit ng parehong hanay ng data sa mga yugto ng pagpapatunay at pag-verify, na nangangailangan ng muling pagsulat sa buong code base. Bilang isang resulta, humiram kami ng isang pamamaraan para sa pagproseso ng mga tagubilin mula sa mga modernong processor: ang bawat isa sa kanila ay nahahati sa maliliit na yugto at ilang mga aksyon ay isinasagawa nang magkatulad sa isang cycle.
Pagkatapos ng isang maliit na adaptasyon ng code, lumikha kami ng pipeline para sa parallel na pagproseso ng transaksyon, kung saan ang transaksyon ay nahahati sa 4 na yugto ng pipeline: pakikipag-ugnayan sa network, pagpapatunay, pagpapatupad at paglalathala ng resulta
Tingnan natin ang isang halimbawa. Mayroon kaming dalawang sistema ng pagproseso, serial at parallel. Dumating ang unang transaksyon at ipinadala para sa pagpapatunay sa parehong mga sistema. Ang pangalawang transaksyon ay agad na dumating: sa isang parallel na sistema ay agad itong dinadala sa trabaho, at sa isang sequential system ay inilalagay ito sa isang pila na naghihintay para sa unang transaksyon na dumaan sa kasalukuyang yugto ng pagproseso. Ibig sabihin, ang pangunahing bentahe ng pagpoproseso ng pipeline ay mas mabilis nating iproseso ang pila ng transaksyon.
Ganito kami nakabuo ng ASTS+ system.
Totoo, hindi rin lahat ay napakakinis sa mga conveyor. Sabihin nating mayroon kaming isang transaksyon na nakakaapekto sa mga array ng data sa isang kalapit na transaksyon; ito ay isang tipikal na sitwasyon para sa isang palitan. Ang naturang transaksyon ay hindi maaaring isagawa sa isang pipeline dahil maaari itong makaapekto sa iba. Ang sitwasyong ito ay tinatawag na data hazard, at ang mga naturang transaksyon ay hiwalay na pinoproseso: kapag ang "mabilis" na mga transaksyon sa pila ay naubos, ang pipeline ay hihinto, ang system ay nagpoproseso ng "mabagal" na transaksyon, at pagkatapos ay sisimulan muli ang pipeline. Sa kabutihang palad, ang proporsyon ng naturang mga transaksyon sa kabuuang daloy ay napakaliit, kaya ang pipeline ay tumitigil nang napakadalang na hindi ito nakakaapekto sa pangkalahatang pagganap.
Pagkatapos ay sinimulan naming lutasin ang problema ng pag-synchronize ng tatlong mga thread ng pagpapatupad. Ang resulta ay isang sistemang nakabatay sa isang ring buffer na may mga cell na nakapirming laki. Sa sistemang ito, ang lahat ay napapailalim sa bilis ng pagproseso; hindi kinokopya ang data.
- Ang lahat ng mga papasok na network packet ay pumapasok sa yugto ng paglalaan.
- Inilalagay namin ang mga ito sa isang array at markahan ang mga ito bilang magagamit para sa yugto #1.
- Dumating na ang pangalawang transaksyon, available na ulit ito para sa stage No.
- Nakikita ng unang thread sa pagpoproseso ang mga available na transaksyon, pinoproseso ang mga ito, at inililipat ang mga ito sa susunod na yugto ng pangalawang thread ng pagproseso.
- Pagkatapos ay pinoproseso nito ang unang transaksyon at ibina-flag ang kaukulang cell
deletedβ ito ay magagamit na ngayon para sa bagong paggamit.
Ang buong pila ay pinoproseso sa ganitong paraan.
Ang pagpoproseso ng bawat yugto ay tumatagal ng mga yunit o sampu-sampung microsecond. At kung gagamit tayo ng karaniwang mga scheme ng pag-synchronize ng OS, mawawalan tayo ng mas maraming oras sa mismong pag-synchronize. Iyon ang dahilan kung bakit nagsimula kaming gumamit ng spinlock. Gayunpaman, ito ay napakasamang anyo sa isang real-time na sistema, at mahigpit na hindi inirerekomenda ng RedHat na gawin ito, kaya nag-aplay kami ng spinlock para sa 100 ms, at pagkatapos ay lumipat sa semaphore mode upang maalis ang posibilidad ng isang deadlock.
Bilang resulta, nakamit namin ang pagganap na humigit-kumulang 8 milyong mga transaksyon bawat segundo. At literal na makalipas ang dalawang buwan tungkol sa LMAX Disruptor nakakita kami ng paglalarawan ng isang circuit na may parehong functionality.
Ngayon ay maaaring magkaroon ng ilang mga thread ng pagpapatupad sa isang yugto. Ang lahat ng mga transaksyon ay naproseso nang paisa-isa, sa pagkakasunud-sunod na natanggap ang mga ito. Bilang resulta, tumaas ang peak performance mula 18 thousand hanggang 50 thousand na transaksyon kada segundo.
Sistema ng pamamahala sa peligro ng palitan
Walang limitasyon sa pagiging perpekto, at sa lalong madaling panahon nagsimula kaming muli ng modernisasyon: sa loob ng balangkas ng ASTS+, sinimulan naming ilipat ang mga sistema ng pamamahala sa peligro at pagpapatakbo ng pag-aayos sa mga autonomous na bahagi. Bumuo kami ng isang nababaluktot na modernong arkitektura at isang bagong hierarchical na modelo ng panganib, at sinubukang gamitin ang klase hangga't maaari fixed_point sa halip ng double.
Ngunit agad na lumitaw ang isang problema: kung paano i-synchronize ang lahat ng lohika ng negosyo na gumagana nang maraming taon at ilipat ito sa bagong sistema? Bilang resulta, ang unang bersyon ng prototype ng bagong sistema ay kailangang iwanan. Ang pangalawang bersyon, na kasalukuyang gumagana sa produksyon, ay batay sa parehong code, na gumagana sa parehong mga bahagi ng kalakalan at panganib. Sa panahon ng pag-unlad, ang pinakamahirap na gawin ay ang git merge sa pagitan ng dalawang bersyon. Ang aming kasamahan na si Evgeniy Mazurenok ay nagsagawa ng operasyong ito bawat linggo at sa bawat oras na siya ay nagmumura nang napakatagal.
Kapag pumipili ng bagong sistema, kailangan naming lutasin kaagad ang problema sa pakikipag-ugnayan. Kapag pumipili ng data bus, kinakailangan upang matiyak ang matatag na jitter at minimal na latency. Ang InfiniBand RDMA network ay pinakaangkop para dito: ang average na oras ng pagproseso ay 4 na beses na mas mababa kaysa sa 10 G Ethernet network. Ngunit ang talagang nakakabighani sa amin ay ang pagkakaiba sa mga percentile - 99 at 99,9.
Siyempre, may mga hamon ang InfiniBand. Una, ibang API - ibverbs sa halip na mga socket. Pangalawa, halos walang malawak na magagamit na open source na mga solusyon sa pagmemensahe. Sinubukan naming gumawa ng sarili naming prototype, ngunit naging napakahirap, kaya pumili kami ng komersyal na solusyon - Confinity Low Latency Messaging (dating IBM MQ LLM).
Pagkatapos ay lumitaw ang gawain ng maayos na paghahati ng sistema ng panganib. Kung aalisin mo lang ang Risk Engine at hindi gagawa ng intermediate node, maaaring paghalo ang mga transaksyon mula sa dalawang source.
Ang tinatawag na mga solusyon sa Ultra Low Latency ay may reordering mode: ang mga transaksyon mula sa dalawang mapagkukunan ay maaaring isaayos sa kinakailangang pagkakasunud-sunod sa oras na matanggap; ito ay ipinatupad gamit ang isang hiwalay na channel para sa pagpapalitan ng impormasyon tungkol sa order. Ngunit hindi pa namin ginagamit ang mode na ito: pinapalubha nito ang buong proseso, at sa ilang mga solusyon ay hindi ito suportado. Bilang karagdagan, ang bawat transaksyon ay kailangang magtalaga ng kaukulang mga timestamp, at sa aming pamamaraan ang mekanismong ito ay napakahirap ipatupad nang tama. Samakatuwid, ginamit namin ang klasikong scheme na may isang broker ng mensahe, iyon ay, sa isang dispatcher na namamahagi ng mga mensahe sa pagitan ng Risk Engine.
Ang pangalawang problema ay nauugnay sa pag-access ng kliyente: kung mayroong ilang mga Risk Gateway, kailangang kumonekta ang kliyente sa bawat isa sa kanila, at mangangailangan ito ng mga pagbabago sa layer ng kliyente. Gusto naming lumayo dito sa yugtong ito, kaya ang kasalukuyang disenyo ng Risk Gateway ay nagpoproseso ng buong stream ng data. Lubos nitong nililimitahan ang maximum throughput, ngunit lubos na pinapasimple ang pagsasama ng system.
Pagdoble
Ang aming system ay hindi dapat magkaroon ng isang punto ng pagkabigo, iyon ay, ang lahat ng mga bahagi ay dapat na nadoble, kabilang ang broker ng mensahe. Nalutas namin ang problemang ito gamit ang CLLM system: naglalaman ito ng RCMS cluster kung saan maaaring gumana ang dalawang dispatcher sa master-slave mode, at kapag nabigo ang isa, awtomatikong lilipat ang system sa isa pa.
Paggawa gamit ang isang backup na data center
Ang InfiniBand ay na-optimize para sa pagpapatakbo bilang isang lokal na network, iyon ay, para sa pagkonekta ng rack-mount na kagamitan, at ang isang InfiniBand network ay hindi maaaring ilagay sa pagitan ng dalawang geographically distributed data centers. Samakatuwid, nagpatupad kami ng tulay/dispatcher, na kumokonekta sa imbakan ng mensahe sa pamamagitan ng mga regular na Ethernet network at nagre-relay ng lahat ng transaksyon sa pangalawang IB network. Kapag kailangan naming mag-migrate mula sa isang data center, maaari naming piliin kung aling data center ang gagana ngayon.
Mga resulta ng
Ang lahat ng nasa itaas ay hindi ginawa nang sabay-sabay; tumagal ito ng ilang mga pag-ulit ng pagbuo ng isang bagong arkitektura. Ginawa namin ang prototype sa loob ng isang buwan, ngunit tumagal ng higit sa dalawang taon upang maipasok ito sa kondisyong gumagana. Sinubukan naming makamit ang pinakamahusay na kompromiso sa pagitan ng pagtaas ng oras ng pagproseso ng transaksyon at pagtaas ng pagiging maaasahan ng system.
Dahil ang system ay lubos na na-update, ipinatupad namin ang pagbawi ng data mula sa dalawang independiyenteng mapagkukunan. Kung ang tindahan ng mensahe ay hindi gumagana nang tama sa ilang kadahilanan, maaari mong kunin ang log ng transaksyon mula sa pangalawang pinagmulan - mula sa Risk Engine. Ang prinsipyong ito ay sinusunod sa buong sistema.
Kabilang sa iba pang mga bagay, napanatili namin ang API ng kliyente upang hindi ang mga broker o sinuman ay nangangailangan ng makabuluhang muling paggawa para sa bagong arkitektura. Kinailangan naming baguhin ang ilang mga interface, ngunit hindi na kailangang gumawa ng mga makabuluhang pagbabago sa operating model.
Tinawag namin ang kasalukuyang bersyon ng aming platform na Rebus - bilang pagdadaglat para sa dalawang pinakakapansin-pansing inobasyon sa arkitektura, Risk Engine at BUS.
Sa una, nais naming ilaan lamang ang bahagi ng paglilinis, ngunit ang resulta ay isang malaking distributed system. Ang mga kliyente ay maaari na ngayong makipag-ugnayan sa alinman sa Trade Gateway, sa Clearing Gateway, o pareho.
Ang nakamit namin sa huli:
Binawasan ang antas ng latency. Sa isang maliit na dami ng mga transaksyon, ang system ay gumagana katulad ng nakaraang bersyon, ngunit sa parehong oras ay maaaring makatiis ng mas mataas na pagkarga.
Ang peak performance ay tumaas mula 50 thousand hanggang 180 thousand na transaksyon kada segundo. Ang karagdagang pagtaas ay nahahadlangan ng nag-iisang stream ng pagtutugma ng order.
Mayroong dalawang paraan para sa higit pang pagpapabuti: parallelizing matching at pagbabago sa paraan ng paggana nito sa Gateway. Ngayon ang lahat ng mga Gateway ay gumagana ayon sa isang pamamaraan ng pagtitiklop, na, sa ilalim ng gayong pagkarga, ay huminto sa paggana nang normal.
Sa wakas, makakapagbigay ako ng ilang payo sa mga tinatapos ang mga enterprise system:
- Maging handa sa pinakamasama sa lahat ng oras. Ang mga problema ay palaging lumitaw nang hindi inaasahan.
- Karaniwang imposibleng mabilis na gawing muli ang arkitektura. Lalo na kung kailangan mong makamit ang pinakamataas na pagiging maaasahan sa maraming indicator. Kung mas maraming node, mas maraming mapagkukunan ang kailangan para sa suporta.
- Ang lahat ng custom at proprietary na solusyon ay mangangailangan ng karagdagang mapagkukunan para sa pananaliksik, suporta at pagpapanatili.
- Huwag ipagpaliban ang paglutas ng mga isyu ng pagiging maaasahan ng system at pagbawi pagkatapos ng mga pagkabigo; isaalang-alang ang mga ito sa paunang yugto ng disenyo.
Pinagmulan: www.habr.com