Kaixo, Habr irakurle! Artikulu honen gaia hondamendiak berreskuratzeko tresnak AERODISK Engine biltegiratze sistemetan ezartzea izango da. Hasieran, bi tresnei buruzko artikulu batean idatzi nahi genuen: erreplikazioa eta metroklusterra, baina, zoritxarrez, artikulua luzeegia izan zen, beraz, bi zatitan banatu genuen artikulua. Goazen sinpletik konplexura. Artikulu honetan, erreplikazio sinkronikoa ezarri eta probatuko dugu; datu-zentro bat botako dugu, eta datu-zentroen arteko komunikazio-kanala hautsi eta zer gertatzen den ikusiko dugu.
Gure bezeroek askotan hainbat galdera egiten dizkigute erreplikazioari buruz, beraz, errepliken ezarpena konfiguratzera eta probatzera pasatu aurretik, biltegiratzeko erreplikazioa zer den apur bat esango dizugu.
Teoria apur bat
Biltegiratze-sistemetan erreplikatzea hainbat biltegiratze-sistemetan aldi berean datuen identitatea bermatzeko etengabeko prozesu bat da. Teknikoki, erreplikazioa bi modutan egiten da.
Erreplikazio sinkronikoa – biltegiratze-sistema nagusiko datuak kopiatzea da eta, ondoren, bi biltegiratze-sistemetatik nahitaezko berrespena ematen da datuak erregistratu eta baieztatu direla. Bi aldeetatik (bi biltegiratze sistemak) baieztatu ondoren datuak erregistratutzat jotzen dira eta lan egin daitezke. Honek erreplikan parte hartzen duten biltegiratze-sistema guztietan datu-identitatea bermatzen du.
Metodo honen abantailak:
- Datuak beti berdinak dira biltegiratze sistema guztietan
Cons:
- Irtenbidearen kostu altua (komunikazio-kanal azkarrak, zuntz optiko garestiak, uhin luzeko transzisoreak, etab.)
- Distantzia murrizketak (hamarka kilometroren barruan)
- Ez dago datu logikoen ustelkeriaren aurkako babesik (datuak biltegiratze sistema nagusian (nahita edo ustekabean) hondatzen badira, automatikoki eta berehala hondatuko dira babeskopian, datuak beti berdinak baitira (hori da paradoxa)
Erreplikazio asinkronoa – hau ere biltegiratze sistema nagusitik babeskopiara datuak kopiatzea da, baina nolabaiteko atzerapenarekin eta beste aldean idazketa berretsi beharrik gabe. Datuekin lan egin dezakezu biltegiratze-sistema nagusian grabatu eta berehala, eta babeskopien biltegiratze-sisteman datuak eskuragarri egongo dira denboraren buruan. Kasu honetan datuen identitatea, noski, ez dago batere ziurtatzen. Babeskopia biltegiratze sistemaren datuak beti dira pixka bat "iraganean".
Erreplikazio asinkronoaren abantailak:
- Kostu baxuko irtenbidea (edozein komunikazio kanal, optika aukerakoa)
- Distantzia mugarik ez
- Babeskopia-biltegiratze-sisteman, datuak ez dira hondatzen nagusian hondatzen badira (denbora batez behintzat); datuak hondatzen badira, beti geldi dezakezu erreplika babeskopiko biltegiratze-sisteman datuak usteltzeko.
Cons:
- Datu-zentro desberdinetako datuak ez dira beti berdinak
Beraz, erreplikazio modua aukeratzea negozio-helburuen araberakoa da. Zuretzat ezinbestekoa bada babeskopiko datu-zentroak datu-zentro nagusiaren datu berdinak edukitzea (hau da, RPOren negozio-eskakizuna = 0), orduan dirua atera beharko duzu eta sinkrono baten mugak jasan beharko dituzu. erreplika. Eta datuen egoeraren atzerapena onargarria bada edo besterik gabe dirurik ez badago, metodo asinkronoa erabili behar duzu zalantzarik gabe.
Era berean, azpimarra dezagun modu bat (zehazkiago, topologia bat) metrokluster gisa. Metrocluster moduan, erreplikazio sinkronikoa erabiltzen da, baina, erreplika arrunt batek ez bezala, metrokluster batek bi biltegiratze-sistemek modu aktiboan funtzionatzeko aukera ematen du. Horiek. ez duzu datu zentro aktiboen eta egonean daudenen arteko bereizketarik. Aplikazioek aldi berean lan egiten dute bi biltegiratze sistemekin, fisikoki datu-zentro desberdinetan kokatuta daudenak. Horrelako topologia batean istripuetan egondako geldialdiak oso txikiak dira (RTO, normalean minutuak). Artikulu honetan ez dugu metroklusterren ezarpena kontuan hartuko, gai hau oso zabala eta zabala baita, beraz, hurrengo artikulu bat eskainiko diogu honen jarraian.
Gainera, sarritan, biltegiratze-sistemen bidezko erreplikazioaz hitz egiten dugunean, jende askok arrazoizko galdera bat egiten du: > “Aplikazio askok erreplika-tresna propioak dituzte, zergatik erabili erreplika biltegiratze sistemetan? Hobe ala txarragoa da?
Hemen ez dago erantzun argirik, beraz, hona hemen aldeko eta kontrako argudioak:
Biltegiratze erreplikaziorako argudioak:
- Irtenbidearen sinpletasuna. Tresna bakarrarekin, zure datu multzo osoa errepika dezakezu, karga mota eta aplikazioa edozein dela ere. Aplikazioetako erreplika bat erabiltzen baduzu, aplikazio bakoitza bereizita konfiguratu beharko duzu. Horietako 2 baino gehiago badaude, orduan hau oso lan-intentsiboa eta garestia da (aplikazioen erreplikazioak normalean aplikazio bakoitzerako lizentzia bereizia eta ez doakoa behar du. Baina behean gehiago).
- Edozer erreplika dezakezu -edozein aplikazio, edozein datu- eta beti izango da koherentea. Aplikazio askok (gehienek) ez dute erreplika-gaitasunik, eta biltegiratze-sistemako erreplikak dira hondamendietatik babesteko modu bakarra.
- Ez dago gehiegi ordaindu beharrik aplikazioaren erreplikazioaren funtzionaltasunagatik. Oro har, ez da merkea, biltegiratze sistemaren erreplika baten lizentziak bezala. Baina biltegiratze-erreplikatzeko lizentzia ordaindu behar duzu behin, eta aplikazio bakoitzaren erreplikaren lizentzia bat erosi behar da aplikazio bakoitzerako. Horrelako aplikazio asko badaude, orduan zentimo polit bat kostatzen da eta biltegiratze-erreplikaziorako lizentzien kostua tanta bat bihurtzen da ozeanoan.
Biltegiratze-erreplikazioaren AURKAKO argudioak:
- Aplikazioen bidezko erreplikak funtzionalitate gehiago ditu aplikazioen beraren ikuspuntutik, aplikazioak hobeto ezagutzen ditu bere datuak (jakina), beraz, haiekin lan egiteko aukera gehiago daude.
- Aplikazio batzuen fabrikatzaileek ez dute beren datuen koherentzia bermatzen erreplikazioa hirugarrenen tresnak erabiliz egiten bada. *
* - tesi polemikoa. Esate baterako, DBMS fabrikatzaile ezagun batek oso denbora luzez ofizialki deklaratzen du bere DBMS modu normalean soilik erreplikatu daitekeela beren bitartekoak erabiliz, eta gainerako erreplikazioa (biltegiratze sistemak barne) "ez da egia". Baina bizitzak erakutsi du hori ez dela horrela. Litekeena da (baina hau ez da ziurra) hau ez da bezeroei lizentzia gehiago saltzeko saiakera zintzoena.
Ondorioz, kasu gehienetan, biltegiratze sistematik erreplikatzea hobea da, zeren Aukera sinpleagoa eta merkeagoa da, baina aplikazioen funtzionaltasun espezifikoak behar direnean kasu konplexuak daude, eta aplikazio-mailako erreplikarekin lan egin behar da.
Teoria eginda, orain praktika
Erreplika gure laborategian konfiguratuko dugu. Laborategiko baldintzetan, bi datu-zentro emulatu genituen (hain zuzen ere, eraikin ezberdinetan ziruditen aldameneko bi rack). Standa Engine N2 biltegiratze sistemak osatzen dute, kable optikoen bidez elkarren artean konektatuta daudenak. Windows Server 2016 exekutatzen duen zerbitzari fisiko bat bi biltegiratze sistemetara konektatuta dago 10 Gb Ethernet erabiliz. Standa nahiko sinplea da, baina horrek ez du funtsa aldatzen.
Eskematikoki honelakoa da:
Logikoki, erreplikazioa honela antolatzen da:
Orain ikus ditzagun orain daukagun erreplikazio-funtzionalitatea.
Bi modu onartzen dira: asinkronoa eta sinkronikoa. Logikoa da modu sinkronikoa distantzia eta komunikazio kanalaren arabera mugatzea. Bereziki, modu sinkronikoak zuntza erabiltzea eskatzen du fisika gisa eta 10 Gigabit Ethernet (edo handiagoa).
Erreplikazio sinkronikorako onartzen den distantzia 40 kilometrokoa da, datu-zentroen arteko kanal optikoaren atzerapenaren balioa 2 milisegundorainokoa da. Oro har, atzerapen handiekin funtzionatuko du, baina gero moteltze handiak izango dira grabaketan zehar (logikoa ere bada), beraz, datu-zentroen arteko erreplikazio sinkronikoa planifikatzen ari bazara, optikaren eta atzerapenen kalitatea egiaztatu beharko zenuke.
Erreplikazio asinkronorako baldintzak ez dira hain larriak. Zehatzago esanda, ez daude batere hor. Lanean dagoen edozein Ethernet konexio balioko du.
Gaur egun, AERODISK ENGINE biltegiratze-sistemak bloke-gailuen (LUN) erreplikazioa onartzen du Ethernet protokoloaren bidez (kobrearen edo optikoaren bidez). Fibre Channel bidez SAN ehun baten bidez erreplikatzea beharrezkoa den proiektuetarako, irtenbide egoki bat gehitzen ari gara, baina oraindik ez dago prest, beraz, gure kasuan, Ethernet bakarrik.
Erreplikak ENGINE serieko edozein biltegiratze sistemen artean funtziona dezake (N1, N2, N4) sistema txikietatik hasi eta zaharrenetara eta alderantziz.
Bi erreplikazio moduen funtzionaltasuna guztiz berdina da. Jarraian eskuragarri dagoenari buruzko xehetasun gehiago daude:
- Erreplika “one to one” edo “one to one”, hau da, bi datu-zentro dituen bertsio klasikoa, nagusia eta babeskopia.
- Erreplikatzea "bat askori" edo "bat askori" da, hau da. LUN bat hainbat biltegiratze-sistematan errepikatu daiteke aldi berean
- Aktibatu, desaktibatu eta "alderantzikatu" erreplikazioa, hurrenez hurren, erreplikazioaren norabidea gaitzeko, desgaitzeko edo aldatzeko
- Erreplikazioa RDG (Raid Distributed Group) eta DDP (Dynamic Disk Pool) multzoetarako eskuragarri dago. Hala ere, RDG multzo bateko LUNak beste RDG batean soilik erreplikatu daitezke. DDPrekin berdin.
Askoz ezaugarri txiki gehiago daude, baina ez dago puntu berezirik zerrendatzeak; konfiguratu ahala aipatuko ditugu.
Erreplikazioa konfiguratzea
Konfigurazio-prozesua nahiko erraza da eta hiru fase ditu.
- Sarearen konfigurazioa
- Biltegiratze konfigurazioa
- Arauak (konexioak) eta mapak ezartzea
Erreplikazioa konfiguratzeko puntu garrantzitsu bat da lehen bi faseak urruneko biltegiratze sisteman errepikatu behar direla, hirugarren fasea - nagusian bakarrik.
Sareko baliabideak konfiguratzea
Lehenengo urratsa erreplika-trafikoa transmitituko den sareko atakak konfiguratzea da. Horretarako, portuak gaitu eta haien IP helbideak ezarri behar dituzu Frontend egokigailuak atalean.
Honen ondoren, pool bat (gure kasuan RDG) eta erreplikatzeko IP birtual bat (VIP) sortu behar ditugu. VIP IP helbide mugikorra da, biltegiratze-kontrolagailuen bi helbide "fisiko" (konfiguratu berri ditugun portuetara) lotuta dagoena. Hau izango da erreplikazio-interfaze nagusia. Ez VIP batekin ere funtzionatu dezakezu, VLAN batekin baizik, etiketatutako trafikoarekin lan egin behar baduzu.
Erreplika baterako VIP bat sortzeko prozesua ez da oso desberdina I/Orako VIP bat (NFS, SMB, iSCSI) sortzeko. Kasu honetan, VIP arrunt bat sortzen dugu (VLAN gabe), baina ziurtatu erreplikatzeko dela adierazten duzula (erakusle hori gabe ezingo dugu arauari VIP gehitu hurrengo urratsean).
VIP-ak flotatzen duen IP ataken azpisare berean egon behar du.
Ezarpen hauek urruneko biltegiratze sistema batean errepikatzen ditugu, IP ezberdin batekin, noski.
Biltegiratze sistema ezberdinetako VIP-ak azpisare ezberdinetan egon daitezke, gauza nagusia haien artean bideratzea da. Gure kasuan, adibide hau zehatz-mehatz erakusten da (192.168.3.XX eta 192.168.2.XX)
Horrek sarearen zatiaren prestaketa osatzen du.
Biltegiratzea konfiguratzea
Erreplika baten biltegiratzea konfiguratzea ohikoa denarekiko desberdina da, soilik mapaketa menu berezi baten bidez egiten dugulako "Erreplikaren mapak". Bestela, dena konfigurazio normalarekin gertatzen den berdina da. Orain, ordenan.
Aurretik sortutako R02 igerilekuan, LUN bat sortu behar duzu. Sor dezagun eta deitu LUN1.
LUN bera ere sortu behar dugu tamaina bereko urruneko biltegiratze sistema batean. Guk sortzen dugu. Nahasmena ekiditeko, deitu dezagun urruneko LUN LUN1R
Dagoeneko existitzen den LUN bat hartu behar bagenu, erreplika konfiguratzean, LUN produktibo hau ostalaritik desmuntatu beharko genuke eta, besterik gabe, tamaina bereko LUN huts bat sortu urruneko biltegiratze sisteman.
Biltegiratze-konfigurazioa osatu da, joan gaitezen erreplikazio-arau bat sortzera.
Erreplikazio-arauak edo erreplikazio-estekak konfiguratzea
Biltegiratze-sisteman LUNak sortu ondoren, momentu honetan nagusia izango dena, LUN1 erreplikazio-araua konfiguratzen dugu 1 biltegiratze sisteman LUN1R 2 biltegiratze-sisteman.
Ezarpena "Urrutiko erreplikazioa" menuan egiten da
Sortu dezagun arau bat. Horretarako, erreplikaren hartzailea zehaztu behar duzu. Bertan konexioaren izena eta erreplikazio mota (sinkronoa edo asinkronoa) ere ezartzen ditugu.
“Urrutiko sistemak” eremuan gure biltegiratze sistema gehitzen dugu2. Gehitzeko, kudeaketa IP biltegiratze sistemak (MGR) eta erreplikazioa egingo dugun urruneko LUNaren izena (gure kasuan, LUN1R) erabili behar dituzu. Kontrol-IP-ak konexio bat gehitzeko fasean bakarrik behar dira; erreplikazio-trafikoa ez da haien bidez transmitituko; aurretik konfiguratutako VIP-a erabiliko da horretarako.
Dagoeneko fase honetan urruneko sistema bat baino gehiago gehi ditzakegu "batetik asko" topologiarako: egin klik "gehitu nodoa" botoian, beheko irudian bezala.
Gure kasuan, urruneko sistema bakarra dago, beraz, horretara mugatzen gara.
Araua prest dago. Kontuan izan automatikoki gehitzen dela errepikapeneko parte-hartzaile guztietan (gure kasuan bi daude). Nahi adina arau sor ditzakezu, edozein LUN kopururako eta edozein norabidetan. Adibidez, karga orekatzeko, LUNen zati bat 1 biltegiratze sistematik 2 biltegiratze sistemara erreplikatu dezakegu, eta beste zatia, aitzitik, 2 biltegiratze sistematik 1 biltegiratze sistemara.
Biltegiratze sistema 1. Sortu eta berehala, sinkronizazioa hasi zen.
Biltegiratze sistema 2. Arau bera ikusten dugu, baina sinkronizazioa dagoeneko amaitu da.
LUN1 biltegiratze sisteman 1. rol nagusian dago, hau da, aktibo dago. LUN1R 2 biltegiratze sisteman Bigarren mailako rola da, hau da, egonean dago 1 biltegiratze sistema huts egiten badu.
Orain gure LUN ostalariarekin konekta dezakegu.
iSCSI bidez konektatuko gara, nahiz eta FC bidez ere egin daitekeen. Erreplika batean iSCSI LUN bidez mapeatzea ez da ia ohiko agertokitik desberdina, beraz, ez dugu hau zehatz-mehatz aztertuko hemen. Bada, prozesu hau artikuluan deskribatzen da "'.
Desberdintasun bakarra da mapak sortzen ditugula "Erreplikazio mapak" menuan
Mapak ezarri eta LUN eman genion ostalariari. Ostalariak LUN ikusi zuen.
Fitxategi-sistema lokal batean formateatzen dugu.
Hori da, konfigurazioa osatu da. Hurrengo probak etorriko dira.
Testing
Hiru eszenatoki nagusi probatuko ditugu.
- Rol-aldaketa arrunta Bigarren mailako > Lehen mailakoa. Rol-aldaketa erregularra behar da, adibidez, datu-zentro nagusian prebentzio-eragiketa batzuk egin behar baditugu eta denbora horretan, datuak eskuragarri egon daitezen, karga babeskopiko datu-zentrora transferitzen dugu.
- Larrialdiko rol-aldaketa Sekundarioa > Lehena (data zentroko hutsegitea). Hau da erreplikazioa dagoen agertoki nagusia, eta datu-zentroko hutsegite osoa bizirik irauten lagun dezake konpainiak denbora luzez gelditu gabe.
- Datu-zentroen arteko komunikazio-kanalen apurketa. Bi biltegiratze-sistemen portaera zuzena egiaztatzea arrazoiren batengatik datu-zentroen arteko komunikazio-kanala erabilgarri ez dagoen baldintzetan (adibidez, hondeamakina leku okerrean zulatu eta optika iluna hautsi).
Lehenik eta behin, gure LUN-en datuak idazten hasiko gara (ausazko datuekin fitxategiak idazten). Berehala ikusten dugu biltegiratze sistemen arteko komunikazio kanala erabiltzen ari dela. Hau erraza da ulertzea erreplikatzeaz arduratzen diren portuen kargaren jarraipena irekitzen baduzu.
Bi biltegiratze-sistemek datu "erabilgarriak" dituzte orain, probari ekin diezaiokegu.
Badaezpada, begiratu ditzagun fitxategietako baten hash batuketak eta idatzi itzazu.
Rol aldaketa arrunta
Rolak aldatzeko eragiketa (erreplikaren norabidea aldatzea) edozein biltegiratze-sistemarekin egin daiteke, baina hala ere bietara joan beharko duzu, lehen mailako mapak desgaitu beharko dituzulako eta Bigarren mailakoan gaitu (Primary bihurtuko dena). ).
Agian arrazoizko galdera bat sortzen da orain: zergatik ez automatizatu hau? Erantzuna hau da: erraza da, erreplikazioa hondamendiei aurre egiteko baliabide sinplea da, eskuzko eragiketetan soilik oinarrituta. Eragiketa hauek automatizatzeko, metrokluster modua dago; guztiz automatizatuta dago, baina bere konfigurazioa askoz korapilatsuagoa da. Metrokluster bat sortzeari buruz idatziko dugu hurrengo artikuluan.
Biltegiratze sistema nagusian, mapak desgaitzen ditugu grabaketa gelditzen dela ziurtatzeko.
Ondoren, biltegiratze-sistemetako batean (berdin da, nagusian edo babeskopian) "Urrutiko erreplikazioa" menuan, hautatu gure konexioa REPL1 eta egin klik "Aldatu rola".
Segundo batzuen buruan, LUN1R (backup biltegiratze sistema) Lehen mailakoa bihurtzen da.
LUN1R biltegiratze sistemarekin mapatzen dugu2.
Horren ondoren, gure E: diskoa automatikoki lotzen da ostalariari, oraingoan bakarrik LUN1R-tik "iritsi" da.
Badaezpada, hash batuketak konparatzen ditugu.
Berdin-berdin. Proba gainditu da.
Hutsegitea. Datu zentroko hutsegitea
Momentuz, ohiko aldaketaren ondoren biltegiratze sistema nagusia 2 eta LUN1R dira, hurrenez hurren. Istripu bat emulatzeko, bi biltegiratze-kontrolagailuak itzaliko ditugu2.
Ez dago gehiago sarbiderik.
Ikus dezagun zer gertatzen ari den biltegiratze sisteman (une honetan babeskopia).
Lehen LUN (LUN1R) ez dagoela erabilgarri ikusten dugu. Errore-mezu bat agertu zen erregistroetan, informazio-panelean eta erreplikazio-arauan bertan. Horren arabera, ostalariaren datuak ez daude une honetan erabilgarri.
Aldatu LUN1 rola Lehen mailakoa.
Ostalariaren mapak egiten ari naiz.
Ziurtatu E unitatea ostalarian agertzen dela.
Hash-a egiaztatzen dugu.
Dena ondo dago. Biltegiratze sistemak arrakastaz bizirik iraun zuen aktibo zegoen datu-zentroaren erorketaren ondorioz. Gutxi gorabeherako denbora erreplikazioa "alderantza" konektatzen eta babeskopiko datu-zentrotik LUN konektatzen igaro genuen 3 minutu ingurukoa izan zen. Argi dago ekoizpen errealean dena askoz ere konplikatuagoa dela, eta biltegiratze sistemekin egindako ekintzez gain, sarean, ostalarietan, aplikazioetan hainbat eragiketa gehiago egin behar dituzula. Eta bizitzan denbora-tarte hori askoz luzeagoa izango da.
Hemen idatzi nahiko nuke dena, proba arrakastaz amaitu dela, baina ez gaitezen presaka. Biltegiratze sistema nagusia "gezurra" da, badakigu "erortzen" zenean, Lehen mailako rolean zegoela. Zer gertatzen da bat-batean pizten bada? Bi rol nagusi izango dira, eta horrek datuen ustelkeria berdin du? Egiazta dezagun orain.
Piztu dezagun bat-batean azpiko biltegiratze sistema.
Minutu batzuetan kargatzen da eta, ondoren, zerbitzura itzultzen da sinkronizazio labur baten ondoren, baina Bigarren Hezkuntzako paperean.
Guztia ondo. Zatitutako garuna ez zen gertatu. Honetaz pentsatu genuen, eta beti erorketa baten ondoren biltegiratze sistema Bigarren Hezkuntzako rola izatera pasatzen da, "bizitzan zehar" zer rol izan zuen kontuan hartu gabe. Orain ziur esan dezakegu datu-zentroaren hutsegitearen proba arrakastatsua izan zela.
Datu-zentroen arteko komunikazio-kanalen porrota
Proba honen zeregin nagusia biltegiratze-sistema ez dela arraro jokatzen hasten ziurtatzea da, aldi baterako bi biltegiratze-sistemen arteko komunikazio-kanalak galdu eta gero berriro agertzen bada.
Beraz. Biltegiratze sistemen arteko hariak deskonektatzen ditugu (imama dezagun hondeamakin batek zulatuta zeudela).
Lehen Hezkuntzan ikusten dugu ez dagoela loturarik DBHrekin.
Bigarren Hezkuntzan ikusten dugu ez dagoela loturarik Lehen Hezkuntzarekin.
Dena ondo funtzionatzen du, eta biltegiratze sistema nagusian datuak idazten jarraitzen dugu, hau da, babeskopiatik desberdinak izango direla bermatuta, hau da, “bereizi” egin direla.
Minutu gutxitan komunikazio kanala “konpontzen” dugu. Biltegiratze-sistemek elkar ikusi bezain laster, datuen sinkronizazioa automatikoki aktibatzen da. Hemen ez da ezer eskatzen administratzaileari.
Denbora pixka bat igaro ondoren, sinkronizazioa amaitu da.
Konexioa berrezarri zen, komunikazio-kanalak galtzeak ez zuen larrialdi egoerarik eragin, eta piztu ondoren, sinkronizazioa automatikoki egiten zen.
Findings
Teoria aztertu dugu: zer behar den eta zergatik, non dauden alde onak eta non dauden kontrakoak. Ondoren, bi biltegiratze sistemen arteko erreplikazio sinkronikoa ezarri dugu.
Ondoren, oinarrizko probak egin ziren ohiko kommutaziorako, datu-zentroko hutsegiterako eta komunikazio-kanaletarako. Kasu guztietan, biltegiratze sistemak ondo funtzionatu zuen. Ez dago datu-galerarik eta administrazio-eragiketak ahalik eta gutxien mantentzen dira eskuzko eszenatoki baterako.
Hurrengoan egoera zaildu eta logika horrek guztiak modu aktibo-aktiboko metrokluster automatizatu batean nola funtzionatzen duen erakutsiko dugu, hau da, bi biltegiratze-sistemak lehen mailakoak direnean, eta biltegiratze-sistemaren hutsegiteen kasuan portaera guztiz automatizatuta dagoenean.
Mesedez, idatzi iruzkinak, poz-pozik jasoko ditugu kritika sendoak eta aholku praktikoak.
Hurrengorarte.
Iturria: www.habr.com