Përshëndetje, lexues të Habrës! Në artikullin e kaluar, ne folëm për një mjet të thjeshtë për qëndrueshmëri në sistemet e ruajtjes AERODISK ENGINE – replikimin. Në këtë artikull, do të shkojmë te një temë më të ndërlikuar dhe interesante – metroklasteri, që është një mjet automatizimi për mbrojtjen nga katastrofat për dy qendra të të dhënave, duke lejuar operimin e tyre në modin aktiv-aktiv. Do të tregojmë, do të shfaqim, do të thyem dhe do të rregullojmë.
Si zakonisht, në fillim teoria
Metroklasteri është një klaster i shpërndarë në disa lokacione brenda qytetit ose rajonit. Fjala "klaster" na sugjeron qartë se kompleksi është automatizuar, pra kalimi i nyjave të klasterit në rast defektesh (failover) ndodh automatikisht.
Këtu ndodhet dallimi kryesor mes metroklasterit dhe replikimit të zakonshëm. Automatizimi i operacioneve. Domethënë, në rast ngjarjesh të ndryshme (dështimi i qendrës së të dhënave, ndërprerja e kanaleve, etj.), sistemi i ruajtjes do të ekzekutojë automatikisht veprimet e nevojshme për të ruajtur aksesin në të dhëna. Me replikat e zakonshme, këto veprime realizohen tërësisht ose pjesërisht manualisht nga administratori.
Për çfarë nevojitet kjo?
Qëllimi kryesor që ndjekin klientët, duke përdorur implementime të ndryshme të metroklasterit, është të minimizojnë RTO (Qëllimi i Kohës së Rikuperimit). Domethënë, të minimizojnë kohën e rikuperimit të shërbimeve IT pas një dështimi. Nëse përdoret replikimi i zakonshëm, koha e rikuperimit do të jetë gjithmonë më e gjatë se koha e rikuperimit me metroklaster. Pse? Shumë thjeshtë. Administratorët duhet të jenë në vendin e punës dhe të kalojnë replikimin manualisht, ndërsa metroklasteri e bën këtë automatikisht.
Nëse nuk keni një administrator të dedikuar që nuk fle, nuk ha, nuk pi duhan dhe nuk është i sëmurë, por që 24 orë në ditë monitoron gjendjen e sistemit të ruajtjes, atëherë nuk ka mundësi të garantoni se administratori do të jetë i disponueshëm për kalimin manual në rast dështimi.
Për rrjedhojë, RTO në rastin e mungesës së metroklasterit ose të një administratori të pavdekur të nivelit 99 do të jetë e barabartë me shumën e kohës së kalimit të të gjitha sistemeve dhe intervalin maksimal të kohës, brenda të cilit administratori do të fillojë të punojë me sistemin e ruajtjes dhe sistemet përkatëse.
Kështu, arrijmë në përfundimin e qartë se metroklasteri duhet të përdoret kur kërkesa për RTO është minuta, e jo orë ose ditë. Domethënë, kur në rastin e rënies më të keqe të qendrës së të dhënave, departamenti IT duhet të sigurojë biznesit një kohë rikuperimi të aksesit në shërbimet IT brenda minutash, ose madje sekondash.
Si funksionon?
Në nivelin më të ulët, metroklasteri përdor mekanizmin e replikimit të sinkronizuar të të dhënave, të cilin e kemi përshkruar në artikullin e kaluar (shih. ). Pasi replikimi është i sinkronizuar, atëherë kërkesat për të janë përkatëse, dhe më saktë:
- fibra optike si fizikë, Ethernet 10 gigabit (ose më lart);
- distanca ndërmjet qendrave të të dhënave nuk duhet të jetë më shumë se 40 kilometra;
- vonesa e kanalit optik ndërmjet qendrave të të dhënave (ndërmjet sistemeve të ruajtjes) deri në 5 milisekonda (optimalisht 2).
Të gjitha këto kërkesa janë rekomanduese, që do të thotë se metroklasteri do të funksionojë edhe nëse këto kërkesa nuk respektohen, por duhet të kuptohet se pasojat e mosrespektimit të këtyre kërkesave janë ngadalësimi i punës së të dyja sistemeve të ruajtjes në metroklaster.
Pra, për të transferuar të dhënat ndërmjet sistemeve të ruajtjes përdoret replikimi sinkron, dhe si kalohen automatikisht replikat dhe më e rëndësishmja, si të shmangim split-brain? Për këtë, në nivelin e mëparshëm përdoret një entitet shtesë – arbitri.
Si funksionon arbitri dhe cila është detyra e tij?
Arbitri përbën një makinë virtuale të vogël, ose një klaster hardware që duhet të aktivizohet në një lokacion të tretë (p.sh., në zyrë) dhe të sigurojë akses në sistemin e ruajtjes përmes ICMP dhe SSH. Pas aktivizimit, arbitrit do t'i përcaktohet një IP, dhe pastaj nga sistemi i ruajtjes do të tregohet adresa e tij, plus adresat e kontrolleve të largëta që marrin pjesë në metroklaster. Pas kësaj, arbitri është gati për punë.
Arbitri kryen monitorimin e vazhdueshëm të të gjitha sistemeve të ruajtjes në metroklaster dhe në rast të pamundësisë së ndonjë sistemi të ruajtjes, ai, pas konfirmimit të pamundësisë nga një pjesëmarrës tjetër të klasterit (një nga sistemet e ruajtjes "të gjalla"), merr vendimin për fillimin e procedurës së kalimit të rregullave të replikimit dhe të mapimit.
Një pikë shumë e rëndësishme. Arbitri gjithmonë duhet të gjendet në një lokacion të ndryshëm nga ato ku ndodhen sistemet e ruajtjes, domethënë as në qendrën e të dhënave 1, ku ndodhet sistemi 1, as në qendrën e të dhënave 2, ku është instaluar sistemi 2.
Pse? Sepse vetëm kështu arbitri, me ndihmën e një prej sistemeve të mbijetuara, mund të përcaktojë qartë dhe pa gabime rënien e ndonjë prej dy lokacioneve ku janë vendosur sistemet e ruajtjes. Çdo mënyrë tjetër e vendosjes së arbitrit mund të çojë në split-brain.
Tani tani, le të hedhim një vështrim në detajet e funksionimit të arbitrave.
Arbitri aktivizon disa shërbime që monitorojnë vazhdimisht të gjithë kontrollorët e ruajtjes. Nëse rezultati i monitorimit ndryshon nga i mëparshmi (i disponueshëm / i paqëndrueshem), ai regjistrohet në një bazë të vogël të dhënash që funksionon gjithashtu në arbitr.
Le të shqyrtojmë logjikën e funksionimit të arbitrave më në detaje.
Hapi 1. Identifikimi i papërshtatshmërisë. Ngjarja sinjalizuese për dështimin e ruajtjes është mungesa e ping-ut nga të dy kontrollorët e një ruajtjeje për 5 sekonda.
Hapi 2. Aktivizimi i procedurës së kalimit. Pasi arbitri të kuptojë se një nga ruajtësit është i paqëndrueshëm, ai dërgon një kërkesë tek ruajtësi 'i gjallë' për t'u siguruar se ruajtësi 'i vdekur' është me të vërtetë i vdekur.
Pasi të marrë një komandë të tillë nga arbitri, ruajtësi i dytë (i gjallë) kontrollon përsëri disponueshmërinë e ruajtësit të parë që ka rënë, dhe nëse ai nuk është i disponueshëm, dërgon një konfirmim te arbitri për të pohuar dyshimin e tij. Ruajtësi është, me të vërtetë, i paqëndrueshëm.
Pasi të marrë një konfirmim të tillë, arbitri aktivizon procedurën e largët për kalimin e replikacionit dhe ngritjen e hartës në ato replika që kanë qenë aktive (primary) në ruajtësin e rënë, dhe dërgon një komandë te ruajtësi i dytë për t’i bërë këto replika nga secondary në primary dhe për të ngritur hartën. Po ashtu, ruajtësi i dytë, përkatësisht, i realizon këto procedura, pas të cilave siguron aksesin në LUN-at e humbura nga ai.
Pse është e nevojshme një verifikim shtesë? Për kvorumin. Pra, shumica e numrit të çifteve (3) të pjesëmarrësve në grupin e klasterit duhet të konfirmojnë rënien e një prej nyjave të klasterit. Vetëm atëherë kjo vendimmarrje do të ishte e saktë. Kjo bëhet për të shmangur kalimin e gabuar dhe, përkatësisht, split-brain.
Hapi 2 zgjat rreth 5 – 10 sekonda, kështu që, duke marrë parasysh kohën e nevojshme për të identifikuar papërshtatshmërinë (5 sekonda), brenda 10 – 15 sekondave pas aksidentit, LUN-at me ruajtësin e rënë do të jenë automatikisht të disponueshëm për t'u punuar me ruajtësin e gjallë.
Natyrisht, për të shmangur shkëputjen e lidhjeve me hostet, është e nevojshme të sigurohet gjithashtu një konfigurim i saktë i skadencave në hoste. Skadenca e rekomanduar është të paktën 30 sekonda. Kjo do të parandalojë hostin që të shkëputë lidhjen me ruajtësin gjatë kalimit të ngarkesës në rast aksidenti dhe do të garantojë mungesën e ndërprerjeve në input-output.
Pauzë, përkthehet se nëse metroklasteri është kaq i mirë, pse nevojitet ndonjëherë replikim i zakonshëm?
Në fakt, gjërat nuk janë aq të thjeshta.
Le të shqyrtojmë përfitimet dhe disavantazhet e metroklasterit.
Pra, kemi kuptuar se përfitimet evidente të metroklasterit krahasuar me replikimin e zakonshëm janë:
- Automatizimi i plotë, i cili garanton kohë minimale rikuperimi në rast katastrofe;
- Dhe kjo është gjithçka :-).
Tani, vini re disavantazhet:
- Kostoja e zgjidhjes. Edhe pse metroklasteri në sistemet Aerodisk nuk kërkon licencë shtesë (po përdoret e njëjta licencë si për replikën), kostoja e zgjidhjes do të jetë ende më e lartë se përdorimi i replikimit sinkron. Duhet të realizohen të gjitha kërkesat për replikim sinkron, plus kërkesat e metroklasterit që lidhen me komunikim shtesë dhe një platformë të tretë (shih planifikimin e metroklasterit);
- Kompleksiteti i zgjidhjes. Metroklasteri është ndërtuar në mënyrë që të jetë shumë më kompleks se një replik i zakonshëm dhe kërkon shumë më tepër vëmendje dhe përpjekje për planifikim, konfigurim dhe dokumentacion.
Si përfundim. Metroklasteri është, pa dyshim, një zgjidhje shumë teknologjike dhe e mirë, kur ju nevojitet që të garantoni RTO në sekonda ose minuta. Por nëse një detyrë e tillë nuk ekziston, dhe RTO në orë është në rregull për biznesin, atëherë nuk ka kuptim të përdoret një armë për të gjuajtur shqiponjat. Mjafton një replikim i zakonshëm punëtorësh, sepse metroklasteri do të shkaktojë shpenzime shtesë dhe do të komplikojë infrastrukturën IT.
Planifikimi i metroklasterit.
Ky seksion nuk pretendon të jetë një udhëzues gjithëpërfshirës për projektimin e metroklasterit, por thjesht tregon drejtimet kryesore që duhet të studiohen nëse keni vendosur të ndërtoni një sistem të tillë. Prandaj, kur implementoni një metroklaster, sigurohuni të përfshini për konsultime prodhuesin e ruajtjes (domethënë ne) dhe sistemet e tjera përkatëse.
Platformat.
Siç përmendet më sipër, për elektroklasterin kërkojnë të paktën tri platforma. Dy Qendra të Dhënash, ku do të punojnë ruajtësit dhe sistemet përkatëse, si dhe një platformë të tretë, ku do të funksionojë arbitri.
Distanca e rekomanduar midis Qendrave të të Dhënave nuk duhet të kalojë 40 kilometra. Një distancë më e madhe do të sjellë me shumë gjasë vonesa shtesë, të cilat në rastin e metrokasterit janë jashtëzakonisht të padëshirueshme. Të kujtojmë, vonesat duhet të jenë deri në 5 milisekonda, megjithatë është e preferueshme të gjojmë brenda 2.
Rekomandohet të kontrolloni vonesat edhe gjatë planifikimit. Çdo ofrues më shumë ose më pak i avancuar, që ofron fibra optike midis Qendrave të të Dhënave, mund të organizojë një kontroll cilësor mjaft shpejt.
Sa i përket vonesave deri te arbitri (pra midis platformës së tretë dhe dy të parave), pragu i rekomanduar i vonesave është deri në 200 milisekonda, pra një lidhje e zakonshme VPN korporative mbi Internetin do të ishte e përshtatshme.
Çfarë lidhjeje dhe rrjeti
Në dallim nga skema me replikim, ku mjafton të lidhni sistemet e ruajtjes nga platforma të ndryshme, skema me metrokasterin kërkon lidhjen e hosteve me të dy sistemet e ruajtjes në platforma të ndryshme. Për ta bërë më të qartë diferencën, të dy skemat janë treguar më poshtë.
Siç mund të shihet nga skema, hostet e platformës së parë shikojnë si në sistemin e ruajtjes 1, ashtu edhe në sistemin e ruajtjes 2. Po ashtu, në mënyrë të kundërt, hostet e platformës së dytë shikojnë si në sistemin e ruajtjes 2 ashtu edhe në sistemin e ruajtjes 1. Pra, çdo host e sheh të dy sistemet e ruajtjes. Ky është një kusht i domosdoshëm për funksionimin e metrokasterit.
Natyrisht, nuk ka nevojë që çdo host të çojë një kabllo optike në Qendrën e të Dhënave tjetër, pasi nuk do të mjaftonin portet dhe kabllot. Të gjitha këto lidhje duhet të realizohen përmes switch-ev Ethernet 10G+ ose FibreChannel 8G+ (FC vetëm për lidhjen midis hosteve dhe sistemit të ruajtjes për IO, kanali i replikimit aktualisht është i arritshëm vetëm nëpërmjet IP (Ethernet 10G+).
Tani disa fjalë mbi topologjinë e rrjetit. Një pikë e rëndësishme është konfigurimi i saktë i subnet-eve. Duhet të përcaktohen menjëherë disa subnet-e për lloje të ndryshme trafikesh:
- Subnete për replikim, nëpërmjet të cilave do të sinkronizohen të dhënat mes sistemeve të ruajtjes. Mund të ketë disa, në këtë rast nuk ka rëndësi, gjithçka varet nga topologjia aktuale (e realizuar tashmë) e rrjetit. Nëse ka dy, atëherë, natyrisht, duhet të konfigurohet ruterimi midis tyre;
- Subnete për ruajtjen e të dhënave, përmes të cilave hostet do të kenë qasje në burimet e sistemit të ruajtjes (nëse është iSCSI). Duhet të ketë nga një në çdo Qendër të të Dhënave;
- Subnete menaxhuese, pra tri subnete që mund të ruterizohen në tri platforma, nga të cilat realizohet menaxhimi i sistemit të ruajtjes, dhe gjithashtu aty ndodhet arbitri.
Subnetet për qasje në burimet e hosteve nuk i shqyrtojmë këtu, pasi ato varen shumë nga detyrat.
Ndarja e trafikëve të ndryshëm në subnet-e të ndryshme është shumë e rëndësishme (sidomos është e rëndësishme që të ndahet replikimi nga input-output), sepse nëse e bashkoni të gjithë trafikun në një subnet "të trashë", atëherë nuk do të jetë e mundur të menaxhoni këtë trafik, dhe në kushtet e dy Qendrave të të Dhënave, mund të shkaktojë variante të ndryshme të përplasjeve rrjetërore. Në këtë çështje, në kuadër të këtij artikulli nuk do të thellohemi shumë, pasi për planifikimin e një rrjeti të shtrirë midis Qendrave të të Dhënave mund të liremni në burime të prodhuesve të pajisjeve rrjetërore, ku është përshkruar shumë hollësisht.
Konfigurimi i arbitrit
Arbitrit i duhet të sigurojë akses në të gjitha ndërfaqet menaxhuese të sistemit të ruajtjes përmes protokolleve ICMP dhe SSH. Gjithashtu, duhet të mendohet për qëndrueshmërinë e arbitrit. Këtu ka një çështje.
Qëndrueshmëria e arbitrit është shumë e dëshirueshme, por jo e detyrueshme. Çfarë do të ndodhë nëse arbitri shembet në momentin e gabuar?
- Funksionimi i metrokasterit në mënyrë të rregullt nuk do të ndryshojë, pasi arbitri nuk ndikon aspak në funksionimin e metrokasterit në mënyrën e tij të zakonshme (detyra e tij është të kalojë në kohë ngarkesën midis Qendrave të të Dhënave)
- Megjithatë, nëse arbitri bie për një arsye ose një tjetër dhe "faton" një emergjencë në Qendrën e të Dhënave, atëherë nuk do të ketë asnjë kalim, sepse nuk ka askënd që të japë komandat e nevojshme për kalim dhe të organizojë kuorum. Në këtë rast, metrokasteri do të shndërrohet në një skemë të zakonshme me replikim, të cilën do të duhet ta kalosh manualisht gjatë katastrofës, e cila do të ndikojë në RTO.
Çfarë vjen më pas? Nëse në të vërtetë duhet të sigurosh një nivel minimal të RTO, duhet të sigurosh qëndrueshmërinë e arbitrit. Për këtë ka dy opsione:
- Të nisin një makinë virtuale me arbitrin në një hipervizor të qëndrueshëm, pasi të gjitha hipervizorët e avancuar mbështesin qëndrueshmërinë;
- Nëse në platformën e tretë (në një zyrë hipotetike) është e vështirë të vendosësh një klaster të mirë, nuk ka asnjë klaster ekzistues hipervizorësh, ne kemi paraparë një variant harduerik të arbitrit, i cili është realizuar në një kuti 2U, në të cilën punojnë dy servera të zakonshëm x-86 dhe që mund të përballojë një dështim lokal.
Ne rekomandojmë në mënyrë të ngjashme të sigurohet që arbitri të jetë i qëndrueshëm, pavarësisht se në mënyrë normale nuk është i nevojshëm për metrokasterin. Por siç tregon teoria dhe praktika, nëse dëshirojmë të krijojmë një infrastrukturë të vërtetë të besueshme ndaj katastrofave, është më mirë të mbrohemi. Më mirë të mbrojmë veten dhe biznesin nga 'ligji i mjerimit', që do të thotë nga dështimi i papritur të arbitrit dhe një nga platformat ku ndodhet SCSI.
Arkitektura e zgjidhjes
Duke marrë parasysh kërkesat e mësipërme, ne arrijmë në arkitekturën e përgjithshme të zgjidhjes.
LUN-et duhet të shpërndahen në mënyrë të barabartë midis dy platformave për të shmangur ngarkesën e madhe. Në të njëjtën kohë, gjatë analizës së sizimit në të dyja Qendrat e të Dhënave, duhet të parashikohet jo vetëm dyfishi i vëllimit (i nevojshëm për ruajtjen e të dhënave në të dy SCSI-të), por edhe dyfishi i performancës në IOPS dhe MB/s, për të shmangur degradimin e aplikacioneve në kushtet e dështimit të një nga Qendrat e të Dhënave.
Dua të theksoj se me një qasje të duhur në sizim (dmth, duke siguruar kufijtë e nevojshëm të IOPS dhe MB/s, si dhe burimet e nevojshme të CPU dhe RAM) gjatë dështimit të një nga SCSI-të në metrokaster, nuk do të ketë një rënie të rëndësishme të performancës kur punojmë me një SCSI.
Kjo shpikohet nga fakti se gjatë punës së dy platformave, replikimi sinqyr që funksionon 'han' gjysmën e performancës gjatë shkrimit, sepse çdo transaksion duhet të regjistrohet në dy SCSI (si RAID-1/10). Pra, gjatë dështimit të një nga SCSI-të, ndikimi i replikimit përkohësisht (deri sa të riparohen SCSI-të e dështuar) zhduket dhe ne marrim një rritje dyfish të performancës për shkrim. Pas që LUN-et e SCSI-t të dështuar të rindez venë në SCSI-në e punës, kjo rritje dyfish do të zhduket nga ngarkesa e LUN-eve të SCSI-t tjetër, dhe ne kthehemi në nivelin e njëjtë të performancës që kishim para 'dështimit', por vetëm në kuadër të një platforme.
Me një sizim të mençur, mund të sigurojmë kushte, në të cilat dështimi i një tërë SCSI nuk do të ndjehet fare nga përdoruesit. Por përsëri, kjo kërkon një sizim shumë të kujdesshëm, për të cilin, me të vërtetë, mund të na kontaktoni pa pagesë :-).
Konfigurimi i metrokasterit
Konfigurimi i metrokasterit është shumë i ngjashëm me konfigurimin e replikimit të zakonshëm, që e përshkruam në . Prandaj, do të përqendrohemi vetëm në dallimet. Ne kemi konfiguruar në laboratorin tonë një qëndrim, të bazuar në arkitekturën e mësipërme, në versionin minimal: dy SCSI, të lidhura përmes 10G Ethernet midis tyre, dy switch-e 10G dhe një host, i cili shikon përmes switcheve të dy SCSI me porte 10G. Arbitri funksionon në një makinë virtuale.
Kur konfigurojmë VIP (IP virtuale) për replikat, duhet të zgjedhim llojin e VIP - për metrokaster.
Kemi krijuar dy lidhje replikimi për dy LUN-et dhe i kemi shpërndarë ato në dy SCSI: LUN TEST Primary në SCSI1 (lidhja METRO), LUN TEST2 Primary për SCSI2 (lidhja METRO2).
Për to kemi konfiguruar dy targeta të njëjtë (në rastin tonë iSCSI, por përkrahim edhe FC, logjika e konfigurimit është e njëjtë).
SCSI1:
SCSI2:
Për lidhjet e replikimit kemi bërë mapimet në çdo SCSI.
SCSI1:
SCSI2:
Konfiguruam multipath dhe e prezantuam në host.
Konfigurojmë arbitrin
Me arbitrin vetë nuk ka shumë për të bërë, duhet thjesht ta aktivizoni në platformën e tretë, të caktoni IP-në dhe të konfigurojmë qasjen për ICMP dhe SSH. Vetë konfigurimi bëhet nga SCSI-të. Në të njëjtën kohë, konfigurojmë arbitrin mjafton të bëhet një herë në cilindo nga kontrollet e SCSI-në në metrokaster, këto cilësime do të shtrihen automatikisht në të gjithë kontrollet.
Në seksionin Replikimi i Udhës>> Metrokaster (në cilindo kontrollor)>> butoni "Konfiguro".
Futni IP-në e arbitrit, si dhe ndërfaqet e menaxhimit të dy kontrolleve të SCSI të largët.
Pas kësaj duhet të aktivizoni të gjitha shërbimet (butoni "Rinisni gjithçka"). Në rastin e ri-konfigurimi në të ardhmen, do të nevojitet të rinisni shërbimet, për t'u siguruar që cilësimet të hyjnë në fuqi.
Kontrollojmë që të gjitha shërbimet janë aktivizuar.
Kështu, konfigurimi i metrokasterit përfundon.
Testimi i dështimit
Testimi i dështimit në rastin tonë do të jetë mjaft i thjeshtë dhe i shpejtë, pasi funksionaliteti i replikimit (kalimi, konsistenca etj.) është trajtuar në . Pra, për të provuar besueshmërinë e metrokasterit, mjafton të kontrollojmë automatizimin e identifikimit të dështimit, kalimin dhe mungesën e humbjeve gjatë shkrimit (ndalimi i hyrjes dhe daljes).
Për këtë, ne simullojmë një dështim të plotë të një SCSI, duke e fikur fizikisht të dy kontrollorët e saj, duke nisur më parë kopjimin e një file të madh në LUN, i cili duhet të aktivizohet në SCSI-në tjetër.
Ndërpresim një SHTD. Në SHTD-në e dytë shohim alerte dhe mesazhe në log, që tregojnë se lidhja me sistemin fqinj është humbur. Nëse janë të konfiguruara njoftimet përmes SMTP ose SNMP monitorimi, administratori do të marrë njoftimet përkatëse.
Sikur të kalojnë 10 sekonda (duket në të dyja screenshot-et) lidhja e replikimit METRO (ajo, që ishte Primary në SHTD-në që ra) automatikisht u bë Primary në SHTD-në që funksionon. Duke përfituar nga hartimi ekzistues, LUN TEST mbeti i aksesueshëm për host-in, shkrimi ra pak (brenda 10% të premtuar), por nuk u ndërpre.
Testi përfundoi me sukses.
Të përmbledhim
Implementimi aktual i metroklastit në sistemet e ruajtjes AERODISK Engine N-seri plotësisht i mundëson zgjidhjen e detyrave, ku kërkohet që të përjashtohet ose minimizohet koha e ndërprerjes së shërbimeve IT dhe të sigurohet funksionimi i tyre në modin 24/7/365 me shpenzime minime pune.
Mund të thuhet, sigurisht, se e gjithë kjo është teori, kushte ideale laboratorike dhe kështu me radhë... POR ne kemi një sërë projektesh të realizuara, në të cilat kemi realizuar funksionalitetin e qëndrueshmërisë ndaj fatkeqësive, dhe sistemet funksionojnë shkëlqyeshëm. Një nga klientët tanë mjaft të njohur, ku përdoren pikërisht dy SHTD në një konfigurim qëndrese ndaj fatkeqësive, tashmë ka dhënë miratimin për publikimin e informacionit në lidhje me projektin, prandaj në pjesën tjetër do të flasim për implementimin në terren.
Faleminderit, presim një diskutim produktiv.
Burimi: habr.com
