Përshëndetje, lexues të Habrës! Në artikullin e kaluar ne folëm për një mjet të thjeshtë të qëndrueshmërisë ndaj katastrofave në sistemet e ruajtjes AERODISK ENGINE – për replikimin. Në këtë artikull ne do të thellojmë në një temë më të komplikuar dhe interesante – metroklaster, e cila është një mjet i automatizuar për mbrojtjen nga katastrofat për dy Qendrat e Të Dhënave, duke lejuar që Qendrat e Të Dhënave të funksionojnë në modin aktive-aktive. Do të tregojmë, do të shfaqim, do të prishim dhe do të rregullojmë.
Si zakonisht, në fillim teoria
Metroklaster është një klaster i shpërndarë në disa vende brenda qytetit ose rajonit. Fjala "klaster" na sugjeron qartë se kompleksi është automatizuar, që do të thotë se kalimi i nyjave të klasterit në rast të dështimeve ndodh automatikisht.
Këtu qëndron dallimi kryesor midis metroklasterit dhe replikës së zakonshme. Automatizimi i operacioneve. Kështu, në rastin e ndodhisë ndonjë ngjarjeje (dështimi i Qendrës së Të Dhënave, ndërprerja e kanaleve etj.), sistemi i ruajtjes do të kryejë automatikisht veprimet e nevojshme për të ruajtur qasjen në të dhëna. Ndërsa kur përdoren replikat e zakonshme, këto veprime kryhen plotësisht ose pjesërisht manualisht nga administratori.
Për çfarë është kjo e nevojshme?
Qëllimi kryesor që kanë klientët duke përdorur realizime të ndryshme të metroklasterit është minimizimi i RTO (Objective i Kohës për Rindërtim). Kjo do të thotë minimizimi i kohës së rikthimit të shërbimeve IT pas një dështimi. Nëse përdorim replikimin e zakonshëm, koha e rikthimit do të jetë gjithmonë më e gjatë se koha e rikthimit me metroklaster. Pse? Shumë e thjeshtë. Administratori duhet të jetë në vendin e punës dhe të kalojë replikimin me duar, ndërsa metroklaster 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ë, që shikon 24 orë në ditë gjendjen e SHT, atëherë nuk ka mundësi të garantoni se administratori do të jetë i disponueshëm për kalim manual gjatë dështimit.
Prandaj, RTO në rastin e mungesës së metroklasterit ose një administratori të pavdekur të nivelit 99 të shërbimit të administratorëve do të jetë i barabartë me shumën e kohës së kalimit të të gjitha sistemeve dhe intervalit maksimal të kohës, pas të cilit administratori garanton se do të fillojë të punojë me SHT dhe sistemet e lidhura.
Kështu, arrijmë në përfundimin e qartë se metroklaustri duhet të përdoret në rast se kërkesa për RTO është minuta, e jo orë apo ditë. Pra, kur në rastin e rënies më të keqe të Qendrës së Të Dhënave, departamenti IT duhet të sigurojë biznesit kohën për rikthimin e aksesit në shërbimet IT brenda minutash, madje edhe sekondash.
Si funksionon kjo?
Në nivele më të ulëta, metroklaustri përdor mekanizmin e replikimit sinkronik të të dhënave, të cilin e përshkruam në artikullin e mëparshëm (shih. ). Duke qenë se replikimi është sinkronik, kërkesat për të janë përkatëse, konkretisht:
- fibra optike si fizikë, Ethernet 10 gigabit (ose më i lartë);
- distanca midis Qendrave të Të Dhënave nuk duhet të jetë më shumë se 40 kilometra;
- vonesa e kanalit të optikës midis Qendrave të Të Dhënave (midis SHT) deri në 5 milisekonda (optimale 2).
Të gjitha këto kërkesa janë rekomanduese, domethënë metroklaustri do të punojë edhe nëse këto kërkesa nuk respektohen, por duhet kuptuar se pasojat e mosrespektimit të këtyre kërkesave janë të ngjashme me ngadalësimin e punës së të dyja SHT-ve në metroklauster.
Pra, për të transferuar të dhëna midis SHT-ve përdoret replikimi sinkronik, dhe si ndodhin automatikisht kalimet e replikave dhe, më e rëndësishmja, si të shmangen split-brain? Për këtë në nivelin e sipërm përdoret një entitet shtesë - arbitri.
Si funksionon arbitri dhe cila është detyra e tij?
Arbitri përbëhet nga një makinë virtuale të vogël, ose një klaster harduerik, i cili duhet të aktivizohet në një vend të tretë (p.sh., në zyrë) dhe të sigurohet qasje në SHT përmes ICMP dhe SSH. Pas aktivizimit, arbitrit i duhet të vendosë IP-në, dhe pastaj nga ana e SHT-së të tregojë adresën e tij, plus adresat e kontrolluesve të largët që marrin pjesë në metroklauster. Pas kësaj, arbitri është gati për punë.
Arbitri kryen monitorim të vazhdueshëm të gjitha SHT-ve në metroklauster dhe në rast se një sistem ruajtjeje është i paarritshëm, ai, pas konfirmimit të paarritshmërisë nga një pjesëmarrës tjetër i klasterit (një nga SHT-të 'aktive'), merr vendimin për të filluar procedurën e kalimit të rregullave të replikimit dhe mapimin.
Një moment shumë i rëndësishëm. Arbitri gjithmonë duhet të jetë në një vend ndryshe nga ata ku ndodhen SHT-të, domethënë as në Qendrën e Të Dhënave 1, ku ndodhet SHT 1, as në Qendrën e Të Dhënave 2, ku është instaluar SHT 2.
Pse? Sepse vetëm kështu arbitri me ndihmën e një nga sistemet e mbetjeve të mbetura mund të përcaktojë njëherë e përgjithmonë rënien e ndonjë prej dy platformave ku janë instaluar sistemet e mbetjeve. Çdo mënyrë tjetër për vendosjen e arbitrit mund të çojë në një situatë split-brain.
Tani le të hedhim një vështrim më të thellë në detajet e punës së arbitrit.
Në arbitër janë të aktivizuara disa shërbime, të cilat vazhdimisht kontrollojnë të gjitha kontrolluesit e sistemit të mbetjeve. Nëse rezultati i kontrollit ndan nga ai i mëparshëm (i arritshëm/jo i arritshëm), atëherë regjistrohet në një bazë të vogël të dhënash, e cila gjithashtu funksionon në arbitër.
Le të shqyrtojmë logjikën e punës së arbitrit më në detaje.
Hapi 1. Përcaktimi i papërshkueshmërisë. Ngjarja-signal për dështimin e sistemit të mbetjeve është mungesa e ping-ut nga të dy kontrolluesit e një sistemi të mbetjeve brenda 5 sekondave.
Hapi 2. Nisja e procedurës së ndryshimit. Pasi arbitri kupton se një nga sistemet e mbetjeve nuk është e arritshme, ai dërgon një kërkesë për sistemin e mbetjeve "të gjallë" për të verifikuar se sistemi "i vdekur" vërtet është vdekur.
Pas marrjes së një urdhri të tillë nga arbitri, sistemi i dytë (i gjallë) kontrollon përsëri aksesin e sistemit të mbetjeve që ka rënë për të verifikuar nëse ajo mungon, dhe nëse ajo nuk është e pranishme, dërgon arbitrit konfirmimin e dyshimit të tij. Sistemi i mbetjeve, vërtet, nuk është i arritshëm.
Pas marrjes së këtij konfirmimi, arbitri nis procedurën e largët të ndryshimit të replikimeve dhe ngritjes së mapimeve në replikat që ishin aktive (primary) në sistemin e mbetjeve që ka rënë, dhe dërgon një komandë për sistemin e dytë për të bërë këto replikate nga secondary në primary dhe për të ngritur mapimin. Ndërkaq, sistemi i dytë, përkatësisht, realizon këto procedura dhe si rezultat siguron qasje në LUN-të e humbura nga vetja.
Pse është e nevojshme verifikimi shtesë? Për kvorum. Pra, shumica e pjesëmarrësve në grupin e çrregullt (3) duhet të konfirmojnë rënien e njërit prej nyjave të grupit. Vetëm atëherë kjo vendim do të jetë saktësisht e saktë. Kjo është e nevojshme për të shmangur ndryshimin e gabuar dhe, për rrjedhojë, një situatë split-brain.
Hapi 2, në kohë, zgjat rreth 5 - 10 sekonda, kështu që duke marrë parasysh kohën që është e nevojshme për të përcaktuar papërshkueshmërinë (5 sekonda), brenda 10 - 15 sekondave pas aksidentit, LUN-të me atë që ka rënë do të jenë automatikisht të arritshme për të punuar me sistemin e mbetjeve të gjallë.
Natyrisht, që për të shmangur shkëputjen e lidhjes me hostët, është e nevojshme të kujdesemi për konfigurimin e saktë të kohëve të pritjes te hostët. Kohëzgjatja e rekomanduar është të paktën 30 sekonda. Kjo do të parandalojë hostin të shkëputet nga SAN gjatë kalimit të ngarkesës në rast aksidenti dhe do të garantojë mungesën e ndërprerjes së hyrjes/daljes.
Po, nëse metroklastri është kaq i mirë, përse është e nevojshme replikimi i zakonshëm?
Në të vërtetë, gjithçka nuk është aq e thjeshtë.
Le të shqyrtojmë përparësitë dhe disavantazhet e metroklastrit
Pra, kuptuam se përparësitë e dukshme të metroklastrit krahasuar me replikimin e zakonshëm janë:
- Automatizimi i plotë, duke siguruar kohën minime të rikuperimit në rast katastrofe;
- Dhe kaq :-).
Tani, më vëmendje, disavantazhet:
- Kostoja e zgjidhjes. Edhe pse metroklastri në sistemet Airodisk nuk kërkon licencim shtesë (përdoret e njëjta licencë si ajo për replikën), kostoja e zgjidhjes do të jetë akoma më e lartë se ajo e replikimit sinkron. Do të duhen përmbushur të gjitha kërkesat për replikën sinkron, plus kërkesat për metroklastrin, të lidhura me komunikim shtesë dhe një lokacion të shtuar (shih Planifikimin e Metroklastrit);
- Kompleksiteti i zgjidhjes. Metroklastri është ndërtuar ndjeshëm më komplekse se replikat e zakonshme dhe kërkon më shumë vëmendje dhe punë për planifikim, konfigurim dhe dokumentim.
Në fund. Metroklastri është, pa dyshim, një zgjidhje shumë teknologjike dhe e mirë, kur ju nevojitet me të vërtetë të siguroheni për një RTO në sekonda ose minuta. Por nëse nuk ka një detyrë të tillë, dhe RTO në ore është në rregull për biznesin, atëherë nuk ka kuptim të përdorësh armë të fuqishme për të gjuajtur merimanga. Mjafton një replikim i zakonshëm, pasi metroklastri do të sjellë shpenzime shtesë dhe do të komplikohet infrastruktura IT.
Planifikimi i Metroklastrit
Ky seksion nuk pretendon të jetë një udhëzues gjithëpërfshirës për projektimin e metroklastrit, por tregon vetëm drejtime kryesore që duhet të shqyrtohen, nëse keni vendosur të krijoni një sistem të tillë. Prandaj, gjatë implementimit të metroklastrit, sigurohuni të angazhoni për konsultime prodhuesin e SAN (domethënë ne) dhe sisteme të tjera përkatëse.
Lokacionet
Siç u tha më lart, për një metroklauster janë të nevojshme të paktën tri vendndodhje. Dy DC-të, ku do të funksionojnë sistemet e ruajtjes dhe sistemet përkatëse, si dhe një vendndodhje e tretë, ku do të funksionojë arbitri.
Distanca e rekomanduar midis DC-ve është jo më shumë se 40 kilometra. Një distancë më e madhe me një probabilitet të lartë do të shkaktojë vonesa shtesë, të cilat në rastin e metroklausterit janë jashtëzakonisht të pa dëshiruara. Të kujtojmë, vonesat duhet të jenë deri në 5 milisekonda, megjithëse preferohet të arrijnë në 2.
Rekomandohet që vonesat të kontrollohen gjithashtu gjatë fazës së planifikimit. Çdo ofrues më së paku të rritur, që ofron fibra optike midis DC-ve, mund të organizojë një kontroll të cilësisë mjaft shpejt.
Sa i përket vonesave deri te arbitri (dmth midis vendndodhjes së tretë dhe dy të parave), pragu i rekomanduar i vonesave është deri në 200 milisekonda, kështu që një lidhje tipike VPN korporative mbi internet do të jetë e mjaftueshme.
Shkëmbimi dhe rrjeti
Ndryshe nga skema me replikimin, ku mjafton të lidhësh së bashku sistemet e ruajtjes nga vendndohcje të ndryshme, skema me metroklauster kërkon lidhjen e hosteve me të dy sistemet e ruajtjes në vendndohcje të ndryshme. Për ta bërë më të qartë, dallimi midis dy skemave është i shënuar më poshtë.
Siç tregohet në skemë, ne kemi hostet e vendndodhjes 1 që shohin si në SHD1 ashtu edhe në SHD2. Po ashtu, anasjelltas, hostet e vendndohcjes 2 shohin dhe në SHD2 dhe në SHD1. Pra, çdo host sheh të dy sistemet e ruajtjes. Kjo është një kusht i domosdoshëm për funksionimin e metroklausterit.
Natyrisht, nuk ka nevojë që çdo host të tërheqë një kabllo optike në DC-në tjetër, portet dhe kabllot do të ishin të pamjaftueshme. Të gjitha këto lidhje duhet të kryhen përmes switch-esh Ethernet 10G+ ose FibreChannel 8G+ (FC vetëm për lidhjen e hosteve me sistemet e ruajtjes për IO, kanali i replikimit aktualisht është i disponueshëm vetëm përmes IP (Ethernet 10G+).
Tani disa fjalë për topologjinë e rrjetit. Një pikë e rëndësishme është konfigurimi i saktë i subneteve. Është e nevojshme të përcaktohen disa subnet për lloje të ndryshme të trafikut që në fillim:
- Subnet për replikimin, mbi të cilin do të sinkronizohen të dhënat midis sistemet e ruajtjes. Mund të kenë disa, në këtë rast nuk ka rëndësi, gjithçka varet nga topologjia aktuale (të realizuar tashmë) e rrjetit. Nëse ka dy, padyshim që duhet të konfigurohet rrugëzimi midis tyre;
- N subnetet e ruajtur të të dhënave, përmes të cilave hostet do të kenë qasje në burimet e SΧD (nëse është iSCSI). Këto subnet duhet të jenë një e tillë në secilën qendër të të dhënave;
- Subnetet menaxhuese, pra tre subnet të ruterizueshme në tre lokacione, nga të cilat menaxhohet SΧD dhe aty gjendet arbitri.
Subnetet për qasje në burimet e hosteve këtu nuk shqyrtohen, pasi ato varen shumë nga detyrat.
Ndara e trafikut të ndryshëm në subnet të ndryshme është jashtëzakonisht e rëndësishme (veçanërisht e rëndësishme është të ndahen replikat nga hyrja-dalja), pasi nëse përzihen të gjithë trafiku në një subnet 'të trashë', atëherë ky trafik do të bëhet i pamundur për tu menaxhuar, dhe në kushtet e dy qendrave të të dhënave, kjo mund të shkaktojë variante të ndryshme të kolizionit të rrjetit. Ne nuk do të thellohemi shumë në këtë çështje në kuadër të këtij artikulli, pasi rreth planifikimit të një rrjeti të shtrirë midis qendrave të të dhënave mund të lexoni në burime të prodhuesve të pajisjeve rrjetërore, ku kjo është përshkruar shumë në detaje.
Konfigurimi i arbitrit
Arbitri duhet të sigurojë qasje në të gjitha ndërfaqet menaxhuese të SΧD përmes protokolleve ICMP dhe SSH. Gjithashtu duhet të mendohet për qëndrueshmërinë e arbitrit. Këtu ka një nuancë.
Qëndrueshmëria e arbitrit është shumë e dëshirueshme, por jo e detyrueshme. Çfarë do të ndodhë nëse arbitri bie në një moment të papërshtatshëm?
- Funksionimi normal i metroklastit nuk do të ndryshojë, pasi arbitri nuk ka ndikim mbi funksionimin normal të metroklastit (detyra e tij është të kalojë ngarkesën në kohë midis qendrave të të dhënave)
- Në këtë rast, nëse arbitri bie për ndonjë arsye dhe nuk 'zbulon' një aksident në qendrën e të dhënave, asnjë kalim nuk do të ndodhi, pasi nuk ka askush për të dhënë komandat e nevojshme për kalim dhe për të organizuar kuorumin. Në këtë rast, metroklastri do të kthehet në një skemë të zakonshme me replikim, të cilën do të duhet ta kaloni manualisht gjatë katastrofës, që do të ndikojë në RTO.
Çfarë pasojash nxjerrim nga kjo? Nëse është vërtet e nevojshme të sigurohet një nivel minimal RTO, duhet të sigurohet qëndruese e arbitrit. Për këtë ka dy mundësi:
- Të nisni një virtualizues me arbitrin në një hipervizor të qëndrueshëm, meqenëse të gjitha hipervizorët seriozë e mbështesin qëndrueshmërinë;
- Nëse në lokacionin e tretë (në një zyrë hipotetike) është mërzi të vendosni një grumbull normal dhe nuk ka një grumbull ekzistues të hiperreplikatorëve, ne kemi përcaktuar një variant harduerik të arbitrit, i cili është në një kuti 2U, ku punojnë dy serverë të zakonshëm x-86 dhe që mund të mbijetojë një dështim lokal.
Ne e rekomandojmë me ngulm sigurimin e qëndrueshmërisë së arbitrit, ndonëse në modin standard nuk është e nevojshme për metrokasterin. Por siç tregon teoria dhe praktika, nëse ndërtojmë një infrastrukturë të vërtetë të besueshme, është më mirë të jemi të sigurt. Më mirë ta mbrojmë veten dhe biznesin nga 'ligji i këqijve', domethënë nga dështimi i njëkohshëm i arbitrit dhe një nga lokacionet ku ndodhet sistemi i ruajtjes së të dhënave.
Arkitektura e zgjidhjes
Duke marrë parasysh kërkesat e lartpërmendura, ne marrim arkitekturën e përgjithshme të zgjidhjes.
Duhet të shpërndahen LUN-et në mënyrë të barabartë në dy lokacione, për të shmangur mbingarkesën e madhe. Për këtë arsye, gjatë përllogaritjes në të dy qendrat e të dhënave (datacenters), duhet të përllogariten jo vetëm dyfishi i volumit (i cili është i nevojshëm për ruajtjen e të dhënave në mënyrë simultane në dy sisteme ruajtje të të dhënave), por edhe dyfishi i performancës në IOPS dhe MB/s, për të parandaluar degradimin e aplikacioneve gjatë dështimit të një nga qendrat e të dhënave.
Dua të theksoj veçanti, se me një qasje të duhur ndaj përllogaritjes (domethënë, me kushtin që ne kemi parashikuar kufijtë e nevojshëm të IOPS dhe MB/s, si dhe burimet e nevojshme të CPU dhe RAM), kur një nga sistemet e ruajtjes të të dhënave dështon në metrokaster, nuk do të ketë një rënie të rëndësishme të performancës gjatë punës temporale me një sistem të vetëm.
Kjo shpjegohet nga fakti se në kushtet e punës me dy lokacione, replikimi sinxhron përfundon gjysmën e performancës gjatë shkrimit, pasi çdo transaksion duhet të shkruhet në dy sisteme ruajtje të të dhënave (ngjashëm me RAID-1/10). Pra, gjatë dështimit të një nga sistemet e ruajtjes të të dhënave, ndikimi i replikimit përkohësisht (deri sa të rikonfigurohet sistemi që ka dështuar) zhduket, dhe ne merrni një rritje dyfish të performancës në shkrim. Pas rikonfigurimit të LUN-eve të sistemit të dështuar në sistemin e punës, kjo rritje dyfish zhduket për shkak të ngarkesës nga LUN-et e sistemit tjetër, dhe ne kthehemi në nivelin e njëjtë të performancës që kishim para 'rënies', por tani vetëm brenda një lokacioni.
Me ndihmën e një sizimi të saktë, është e mundur të ofrohet një situatë në të cilën përdoruesit nuk do ta ndiejnë fare dështimin e gjithë SHD-së. Megjithatë, le të theksojmë sërish se kjo kërkon një sizim shumë të kujdesshëm, për të cilin, për fat të mirë, mund të na kontaktoni falas :-).
Konfigurimi i metrokasterit
Konfigurimi i metrokasterit është shumë i ngjashëm me konfigurimin e replikimit të zakonshëm, të cilin e kemi përshkruar në . Prandaj, le të përqendrohemi vetëm në dallimet. Ne kemi vendosur një skenë laboratorike të bazuar në arkitekturën e mësipërme, vetëm në versionin minimal: dy SHD, të lidhura përmes 10G Ethernet me njëra-tjetrën, dy kalimtarë 10G dhe një host, i cili shikon përmes kalimtarëve në të dy SHD-të me portet 10G. Arbitri punon në një makinë virtuale.
Kur konfiguroni IP-të virtuale (VIP) për replikat, duhen zgjedhur llojin e VIP-it - për metrokaster.
Krijuam dy lidhje replikimi për dy LUN-e dhe i shpërndamë ato në dy SHD: LUN TEST Primary në SHD1 (lidhja METRO), LUN TEST2 Primary për SHD2 (lidhja METRO2).
Për to, ne kemi konfigurua dy targeta të njëjtë (në rastin tonë iSCSI, por mbështetet edhe FC, logjika e konfigurimit është e njëjtë).
SHD1:
SHD2:
Për lidhjet e replikimit kemi bërë mapping në çdo SHD.
SHD1:
SHD2:
Konfigurua multipath dhe u prezantua në host.
Konfigurimi i arbitrit
Me vetë arbitrin nuk është nevoja të bëhet ndonjë gjë e veçantë, duhet thjesht të aktivizohet në platformën e tretë, t'i vendoset një IP dhe të konfigurohet qasje përmes ICMP dhe SSH. Konfigurimi i vetë arbitrit kryhet nga vetë SHD-të. Në këtë rast, konfigurimi i arbitrit mjafton të kryhet një herë në cilindo nga kontrolluesit e SHD-së në metrokaster, këto konfigurime do të përhapen automatikisht në të gjithë kontrolluesit.
Në seksionin Replikimi i Largët >> Metrokaster (në çdo kontrollues) >> butoni "Konfiguro".
Shtojmë IP-në e arbitrit, si dhe ndërfaqet menaxhuese të dy kontrolluesve të SHD-së së largët.
Pas kësaj, është e nevojshme të aktivizoni të gjitha shërbimet (butoni "Rivendos të gjitha"). Në rast të ri-konfigurimit në të ardhmen, shërbimet duhet patjetër të rinisen që konfigurimet të hyjnë në fuqi.
Kontrolloni që të gjithë shërbimet janë aktivizuar.
Kjo përfundon konfigurimin e metrokasterit.
Testi i Crash-it
Testi i Crash-it në rastin tonë do të jetë mjaft i thjeshtë dhe i shpejtë, pasi funksionaliteti i replikimit (kalimi, konsistenca, etj.) është trajtuar në Prandaj, për të provuar besueshmërinë e metroklaustrit, mjafton të kontrollojmë automatizimin e zbulimit të aksidenteve, kalimin dhe mungesën e humbjeve gjatë regjistrimit (ndalimin e hyrjes/checkout-it).
Për këtë, ne emulojmë dështimin e plotë të një nga SHKD, duke fikur fizikisht të dy kontrolerët e saj, dhe duke filluar paraprakisht kopjimin e një skedari të madh në LUN, i cili do të aktivizohej në SHKD-në tjetër.
Çdojmë një SHKD. Në SHKD-në e dytë shohim alarma dhe mesazhe në log-et që tregojnë se ka humbur lidhja me sistemin fqinj. Nëse janë vendosur njoftime përmes SMTP ose monitorimi SNMP, atëherë admini do të marrë njoftimet përkatëse.
Saktësisht pas 10 sekondash (e dukshme në të dyja skenarët) lidhja replikatore METRO (ajo që ishte Primare në SHKD-në e rënë) automatikisht u bë Primare në SHKD-në e funksionimit. Duke aktivizuar mapimin ekzistues, LUN TEST mbeti i aksesueshëm për hostin, regjistrimi pak u dobësua (në kufijtë e 10 përqindve të premtuara), por nuk u ndërpre.
Testi përfundoi me sukses.
Përmbledhje
Implementimi aktual i metroklaustrit në sistemet e ruajtjes AERODISK Engine serinë N e lejon plotësisht zgjidhjen e detyrave ku kërkohet të ekskludohen ose minimizohen koha e pezullimit të shërbimeve IT dhe të sigurohet funksionimi i tyre në mënyrë 24/7/365 me minimum të punës.
Natyrisht, mund të thuhet se gjithçka është teori, kushte laboratorike ideale dhe kështu me radhë... POR ne kemi një numër projektesh të implementuara, në të cilat kemi realizuar funksionalitetin përkatës të qëndrueshmërisë ndaj katastrofës, dhe sistemet funksionojnë shkëlqyeshëm. Një nga klientët tanë mjaft të njohur, ku përdoren pikërisht dy SHKD në një konfigurim qëndrueshmërie ndaj katastrofave, ka dhënë tashmë pëlqimin për publikimin e informacionit rreth projektit, kështu që në pjesën tjetër do të flasim për implementimin në terren.
Faleminderit, presim një diskutim produktiv.
Burimi: habr.com
