Sveiki, Habr lasītāji! Šī raksta tēma būs avārijas atkopšanas rīku ieviešana AERODISK Engine uzglabāšanas sistēmās. Sākotnēji gribējām vienā rakstā uzrakstīt par abiem rīkiem: replikāciju un metroklasteri, bet diemžēl raksts izrādījās pārāk garš, tāpēc rakstu sadalījām divās daļās. Pāriesim no vienkārša uz sarežģītu. Šajā rakstā mēs iestatīsim un pārbaudīsim sinhrono replikāciju - atmetīsim vienu datu centru, kā arī pārtrauksim sakaru kanālu starp datu centriem un skatīsimies, kas notiks.
Mūsu klienti mums bieži uzdod dažādus jautājumus par replikāciju, tāpēc, pirms pāriet pie repliku ieviešanas iestatīšanas un testēšanas, mēs nedaudz pastāstīsim par to, kas ir replikācija krātuvē.
Mazliet teorija
Replikācija uzglabāšanas sistēmās ir nepārtraukts process, kas nodrošina datu identitāti vairākās uzglabāšanas sistēmās vienlaikus. Tehniski replikācija tiek veikta divos veidos.
Sinhronā replikācija – tā ir datu kopēšana no galvenās krātuves sistēmas uz rezerves sistēmu, kam seko obligāts apstiprinājums no abām glabāšanas sistēmām, ka dati ir ierakstīti un apstiprināti. Pēc apstiprinājuma no abām pusēm (abām uzglabāšanas sistēmām) dati tiek uzskatīti par ierakstītiem un ar tiem var strādāt. Tas nodrošina garantētu datu identitāti visās uzglabāšanas sistēmās, kas piedalās replikā.
Šīs metodes priekšrocības:
- Dati vienmēr ir identiski visās uzglabāšanas sistēmās
Mīnusi:
- Augstas risinājuma izmaksas (ātrie sakaru kanāli, dārga optiskā šķiedra, garo viļņu raiduztvērēji utt.)
- Attāluma ierobežojumi (vairāku desmitu kilometru rādiusā)
- Nav aizsardzības pret loģisku datu sabojāšanu (ja dati tiek bojāti (tīši vai nejauši) galvenajā krātuves sistēmā, tie automātiski un uzreiz tiks bojāti rezerves sistēmā, jo dati vienmēr ir identiski (tas ir paradokss)
Asinhronā replikācija – tā ir arī datu kopēšana no galvenās krātuves sistēmas uz rezerves sistēmu, taču ar zināmu aizkavi un bez nepieciešamības apstiprināt rakstīšanu otrā pusē. Jūs varat strādāt ar datiem uzreiz pēc to ierakstīšanas galvenajā krātuves sistēmā, un rezerves krātuves sistēmā dati būs pieejami pēc kāda laika. Datu identitāte šajā gadījumā, protams, nemaz netiek nodrošināta. Dublējuma krātuves sistēmas dati vienmēr ir nedaudz “pagātnē”.
Asinhronās replikācijas priekšrocības:
- Zemu izmaksu risinājums (jebkuri sakaru kanāli, optika pēc izvēles)
- Nav attāluma ierobežojumu
- Rezerves krātuves sistēmā dati nepasliktinās, ja tie ir bojāti galvenajā (vismaz kādu laiku); ja dati tiek bojāti, jūs vienmēr varat apturēt reprodukciju, lai novērstu datu sabojāšanu rezerves krātuves sistēmā.
Mīnusi:
- Dati dažādos datu centros vienmēr nav identiski
Tādējādi replikācijas režīma izvēle ir atkarīga no biznesa mērķiem. Ja jums ir svarīgi, lai rezerves datu centrā būtu tieši tādi paši dati kā galvenajā datu centrā (t.i., biznesa prasība RPO = 0), tad jums būs jāizņem nauda un jāsamierinās ar sinhronā datu centra ierobežojumiem. replika. Un, ja datu stāvokļa aizkavēšanās ir pieņemama vai vienkārši nav naudas, tad noteikti ir jāizmanto asinhronā metode.
Atsevišķi izcelsim arī tādu režīmu (precīzāk topoloģiju) kā metroklasteri. Metrocluster režīmā tiek izmantota sinhronā replikācija, taču atšķirībā no parastās replikas metroklasteris ļauj abām uzglabāšanas sistēmām darboties aktīvajā režīmā. Tie. jums nav atdalīts aktīvs un gaidstāves datu centrs. Lietojumprogrammas darbojas vienlaikus ar divām uzglabāšanas sistēmām, kuras fiziski atrodas dažādos datu centros. Dīkstāves negadījumu laikā šādā topoloģijā ir ļoti mazas (RTO, parasti minūtes). Šajā rakstā mēs neaplūkosim mūsu metroklastera ieviešanu, jo šī ir ļoti liela un ietilpīga tēma, tāpēc šī raksta turpinājumā mēs tai veltīsim atsevišķu, nākamo rakstu.
Arī ļoti bieži, kad mēs runājam par replikāciju, izmantojot uzglabāšanas sistēmas, daudziem cilvēkiem rodas pamatots jautājums: > “Daudzām lietojumprogrammām ir savi replikācijas rīki, kāpēc izmantot replikāciju uzglabāšanas sistēmās? Vai tas ir labāk vai sliktāk?
Šeit nav skaidras atbildes, tāpēc šeit ir argumenti PAR un Mīnusi:
Argumenti krātuves replikācijai:
- Risinājuma vienkāršība. Izmantojot vienu rīku, varat replicēt visu datu kopu neatkarīgi no slodzes veida un lietojuma. Ja izmantojat lietojumprogrammu kopiju, katra lietojumprogramma būs jākonfigurē atsevišķi. Ja to ir vairāk nekā 2, tad tas ir ārkārtīgi darbietilpīgi un dārgi (lietojumprogrammas replikācijai parasti ir nepieciešama atsevišķa, nevis bezmaksas licence katrai lietojumprogrammai. Bet par to tālāk).
- Jūs varat replicēt jebko — jebkuru lietojumprogrammu, visus datus — un tas vienmēr būs konsekvents. Daudzām (lielākajai daļai) lietojumprogrammu nav replikācijas iespēju, un kopijas no uzglabāšanas sistēmas ir vienīgais veids, kā nodrošināt aizsardzību pret katastrofām.
- Nav nepieciešams pārmaksāt par lietojumprogrammu replikācijas funkcionalitāti. Parasti tas nav lēts, tāpat kā licences uzglabāšanas sistēmas kopijai. Bet par krātuves replikācijas licenci ir jāmaksā vienu reizi, un lietojumprogrammas replikas licence ir jāiegādājas katrai lietojumprogrammai atsevišķi. Ja šādu lietojumprogrammu ir daudz, tad tas maksā diezgan santīmu, un krātuves replikācijas licenču izmaksas kļūst par pilienu jūrā.
Argumenti PRET krātuves replikāciju:
- Replicēšanai caur lietojumprogrammām ir lielāka funkcionalitāte no pašu lietojumprogrammu viedokļa, lietojumprogramma labāk zina savus datus (acīmredzot), tāpēc ir vairāk iespēju strādāt ar tām.
- Dažu lietojumprogrammu ražotāji negarantē savu datu konsekvenci, ja replikācija tiek veikta, izmantojot trešās puses rīkus. *
* - strīdīga tēze. Piemēram, kāds labi zināms DBVS ražotājs jau ļoti ilgu laiku ir oficiāli paziņojis, ka viņu DBVS var normāli replicēt, tikai izmantojot savus līdzekļus, un pārējā replikācijas daļa (ieskaitot uzglabāšanas sistēmas) nav patiesa. Taču dzīve ir parādījusi, ka tas tā nav. Visticamāk (bet tas nav droši) tas vienkārši nav godīgākais mēģinājums pārdot klientiem vairāk licenču.
Tā rezultātā vairumā gadījumu replikācija no uzglabāšanas sistēmas ir labāka, jo Šī ir vienkāršāka un lētāka iespēja, taču ir sarežģīti gadījumi, kad nepieciešama konkrēta lietojumprogrammas funkcionalitāte, un ir jāstrādā ar lietojumprogrammas līmeņa replikāciju.
Pabeigts ar teoriju, tagad prakse
Mēs konfigurēsim repliku mūsu laboratorijā. Laboratorijas apstākļos mēs emulējām divus datu centrus (faktiski divus blakus esošus statīvus, kas, šķiet, atradās dažādās ēkās). Stends sastāv no divām Engine N2 uzglabāšanas sistēmām, kuras ir savienotas viena ar otru ar optiskiem kabeļiem. Fizisks serveris, kurā darbojas sistēma Windows Server 2016, ir savienots ar abām uzglabāšanas sistēmām, izmantojot 10 Gb Ethernet. Statīvs ir diezgan vienkāršs, bet tas nemaina būtību.
Shematiski tas izskatās šādi:
Loģiski, replikācija tiek organizēta šādi:
Tagad apskatīsim replikācijas funkcionalitāti, kas mums tagad ir.
Tiek atbalstīti divi režīmi: asinhronais un sinhronais. Loģiski, ka sinhrono režīmu ierobežo attālums un sakaru kanāls. Jo īpaši sinhronajam režīmam ir jāizmanto šķiedra kā fizika un 10 gigabitu Ethernet (vai augstāks).
Atbalstītais attālums sinhronai replikācijai ir 40 kilometri, optiskā kanāla aizkaves vērtība starp datu centriem ir līdz 2 milisekundēm. Kopumā tas darbosies ar lielu aizkavi, bet pēc tam ierakstīšanas laikā būs spēcīgi palēninājumi (kas arī ir loģiski), tāpēc, ja plānojat sinhronu replikāciju starp datu centriem, jums vajadzētu pārbaudīt optikas kvalitāti un aizkaves.
Asinhronās replikācijas prasības nav tik nopietnas. Precīzāk, tās tur nemaz nav. Derēs jebkurš strādājošs Ethernet savienojums.
Pašlaik AERODISK ENGINE uzglabāšanas sistēma atbalsta blokierīču (LUN) replikāciju, izmantojot Ethernet protokolu (pa vara vai optisko). Projektiem, kur nepieciešama replikācija caur SAN audumu pa Fibre Channel, šobrīd pievienojam atbilstošu risinājumu, taču tas vēl nav gatavs, tātad mūsu gadījumā tikai Ethernet.
Replicēšana var darboties starp jebkuru ENGINE sērijas uzglabāšanas sistēmu (N1, N2, N4) no jaunākajām sistēmām uz vecākām un otrādi.
Abu replikācijas režīmu funkcionalitāte ir pilnīgi identiska. Tālāk ir sniegta sīkāka informācija par to, kas ir pieejams:
- Replikācija “viens pret vienu” vai “viens pret vienu”, tas ir, klasiskā versija ar diviem datu centriem, galveno un dublējumkopiju
- Replikācija ir “viens pret daudziem” vai “viens pret daudziem”, t.i. vienu LUN var replicēt vairākās uzglabāšanas sistēmās vienlaikus
- Attiecīgi aktivizējiet, deaktivizējiet un "apgrieziet" replikāciju, lai iespējotu, atspējotu vai mainītu replikācijas virzienu
- Replicēšana ir pieejama gan RDG (Raid Distributed Group), gan DDP (Dynamic Disk Pool) pūliem. Tomēr RDG pūla LUN var replicēt tikai citā RDG. Tas pats ar DDP.
Ir daudz vairāk mazu funkciju, taču nav īpašas jēgas tos uzskaitīt; mēs tās pieminēsim iestatīšanas laikā.
Replikācijas iestatīšana
Iestatīšanas process ir diezgan vienkāršs un sastāv no trim posmiem.
- Tīkla iestatīšana
- Krātuves iestatīšana
- Noteikumu (savienojumu) uzstādīšana un kartēšana
Svarīgs punkts replikācijas iestatīšanā ir tas, ka pirmie divi posmi ir jāatkārto attālās krātuves sistēmā, trešais posms - tikai galvenajā.
Tīkla resursu iestatīšana
Pirmais solis ir konfigurēt tīkla portus, caur kuriem tiks pārsūtīta replikācijas trafika. Lai to izdarītu, sadaļā Front-end adapteri ir jāiespējo porti un jāiestata to IP adreses.
Pēc tam mums ir jāizveido pūls (mūsu gadījumā RDG) un virtuālais IP replikācijai (VIP). VIP ir peldoša IP adrese, kas ir saistīta ar divām krātuves kontrolleru “fiziskajām” adresēm (portiem, kurus mēs tikko konfigurējām). Šī būs galvenā replikācijas saskarne. Varat arī darboties nevis ar VIP, bet ar VLAN, ja jums ir nepieciešams strādāt ar tagu trafiku.
VIP izveides process reprodukcijai daudz neatšķiras no VIP izveides I/O (NFS, SMB, iSCSI). Šajā gadījumā mēs izveidojam parastu VIP (bez VLAN), taču noteikti norādiet, ka tas ir paredzēts replikācijai (bez šī rādītāja mēs nevarēsim pievienot VIP kārtulai nākamajā darbībā).
VIP ir jāatrodas tajā pašā apakštīklā ar IP portiem, starp kuriem tas peld.
Mēs atkārtojam šos iestatījumus attālās krātuves sistēmā, protams, ar citu IP.
VIP no dažādām uzglabāšanas sistēmām var atrasties dažādos apakštīklos, galvenais, lai starp tiem būtu maršrutēšana. Mūsu gadījumā šis piemērs ir precīzi parādīts (192.168.3.XX un 192.168.2.XX)
Tas pabeidz tīkla daļas sagatavošanu.
Notiek krātuves iestatīšana
Reprodukcijas krātuves iestatīšana atšķiras no parastās tikai ar to, ka kartēšanu veicam, izmantojot īpašu izvēlni “Replikācijas kartēšana”. Citādi viss ir tāpat kā parastajā iestatījumā. Tagad kārtībā.
Iepriekš izveidotajā pūlā R02 ir jāizveido LUN. Izveidosim to un nosauksim to par LUN1.
Mums ir arī jāizveido tas pats LUN identiska izmēra attālās krātuves sistēmā. Mēs radām. Lai izvairītos no neskaidrībām, izsauksim tālvadības pulti LUN LUN1R
Ja mums vajadzēja izmantot jau esošu LUN, tad, iestatot repliku, šis produktīvais LUN ir jāatvieno no resursdatora un attālajā krātuves sistēmā vienkārši jāizveido tāda paša izmēra tukšs LUN.
Krātuves iestatīšana ir pabeigta, pāriesim pie replikācijas kārtulas izveides.
Replicēšanas kārtulu vai replikācijas saišu iestatīšana
Pēc LUN izveides krātuves sistēmā, kas šobrīd būs primārā, mēs konfigurējam replikācijas kārtulu LUN1 1. krātuves sistēmā uz LUN1R 2. krātuves sistēmā.
Iestatījums tiek veikts izvēlnē “Attālā replikācija”.
Izveidosim noteikumu. Lai to izdarītu, jānorāda kopijas adresāts. Tur mēs arī iestatām savienojuma nosaukumu un replikācijas veidu (sinhronā vai asinhronā).
Laukā “attālās sistēmas” mēs pievienojam mūsu uzglabāšanas sistēmu2. Lai pievienotu, jums ir jāizmanto pārvaldības IP krātuves sistēmas (MGR) un attālā LUN nosaukums, kurā mēs veiksim replikāciju (mūsu gadījumā LUN1R). Kontroles IP ir nepieciešamas tikai savienojuma pievienošanas posmā; caur tiem netiks pārsūtīta replikācijas trafika; šim nolūkam tiks izmantots iepriekš konfigurētais VIP.
Jau šajā posmā topoloģijai “viens pret daudziem” varam pievienot vairāk nekā vienu attālo sistēmu: noklikšķiniet uz pogas “pievienot mezglu”, kā parādīts attēlā zemāk.
Mūsu gadījumā ir tikai viena attālā sistēma, tāpēc mēs aprobežojamies ar to.
Noteikums ir gatavs. Lūdzu, ņemiet vērā, ka tas tiek automātiski pievienots visiem replikācijas dalībniekiem (mūsu gadījumā tie ir divi). Varat izveidot tik daudz šādu noteikumu, cik vēlaties, jebkuram skaitam LUN un jebkurā virzienā. Piemēram, lai līdzsvarotu slodzi, daļu LUN varam replicēt no 1. uzglabāšanas sistēmas uz 2. uzglabāšanas sistēmu, bet otru daļu, gluži pretēji, no 2. uzglabāšanas sistēmas uz 1. uzglabāšanas sistēmu.
Uzglabāšanas sistēma1. Tūlīt pēc izveides sākās sinhronizācija.
Uzglabāšanas sistēma2. Mēs redzam to pašu noteikumu, bet sinhronizācija jau ir beigusies.
LUN1 uzglabāšanas sistēmā 1 ir primārajā lomā, tas ir, tas ir aktīvs. LUN1R 2. uzglabāšanas sistēmā ir sekundārā loma, tas ir, tas ir gaidīšanas režīmā, ja 1. krātuves sistēma neizdodas.
Tagad mēs varam savienot mūsu LUN ar saimniekdatoru.
Mēs pieslēgsimies caur iSCSI, lai gan to var izdarīt arī caur FC. Kartēšanas iestatīšana, izmantojot iSCSI LUN replikā, praktiski neatšķiras no parastā scenārija, tāpēc šeit mēs to sīkāk neapskatīsim. Ja kas, šis process ir aprakstīts rakstā "'.
Vienīgā atšķirība ir tā, ka kartēšanu veidojam izvēlnē “Replikācijas kartēšana”.
Mēs izveidojām kartēšanu un iedevām LUN saimniekam. Saimnieks redzēja LUN.
Mēs to formatējam vietējā failu sistēmā.
Tas arī viss, iestatīšana ir pabeigta. Testi būs nākamie.
Testēšana
Mēs pārbaudīsim trīs galvenos scenārijus.
- Regulāra lomu maiņa Sekundārā > Primārā. Regulāra lomu maiņa ir nepieciešama gadījumā, ja, piemēram, galvenajā datu centrā ir jāveic kādas profilaktiskas darbības un šajā laikā, lai dati būtu pieejami, nododam slodzi uz rezerves datu centru.
- Ārkārtas lomu maiņa Sekundārais > Primārais (datu centra kļūme). Šis ir galvenais scenārijs, kuram pastāv replikācija, kas var palīdzēt pārdzīvot pilnīgu datu centra atteici, neapturot uzņēmumu uz ilgāku laiku.
- Sakaru kanālu sadalījums starp datu centriem. Divu uzglabāšanas sistēmu pareizas uzvedības pārbaude apstākļos, kad nez kāpēc nav pieejams sakaru kanāls starp datu centriem (piemēram, ekskavators izrakās nevietā un salauza tumšo optiku).
Pirmkārt, mēs sāksim rakstīt datus savā LUN (rakstīt failus ar nejaušiem datiem). Mēs uzreiz redzam, ka tiek izmantots sakaru kanāls starp uzglabāšanas sistēmām. To ir viegli saprast, ja atverat par replikāciju atbildīgo portu slodzes uzraudzību.
Abām uzglabāšanas sistēmām tagad ir “noderīgi” dati, varam sākt testu.
Katram gadījumam apskatīsim kāda faila jaucējsummas un pierakstīsim tās.
Regulāra lomu maiņa
Lomu maiņas darbību (replicēšanas virziena mainīšanu) var veikt ar jebkuru krātuves sistēmu, taču jums joprojām būs jāiet uz abām, jo primārajā kartē ir jāatspējo un sekundārajā (kas kļūs par primāro) ir jāatspējo kartēšana. ).
Varbūt tagad rodas pamatots jautājums: kāpēc gan to neautomatizēt? Atbilde ir: tā ir vienkārša, replikācija ir vienkāršs līdzeklis pretestības nodrošināšanai pret katastrofām, kura pamatā ir tikai manuālas darbības. Lai automatizētu šīs darbības, ir metroklastera režīms, tas ir pilnībā automatizēts, taču tā konfigurācija ir daudz sarežģītāka. Par metroklastera izveidi mēs rakstīsim nākamajā rakstā.
Galvenajā krātuves sistēmā mēs atspējojam kartēšanu, lai nodrošinātu ierakstīšanas pārtraukšanu.
Pēc tam vienā no uzglabāšanas sistēmām (nav svarīgi, galvenajā vai rezerves) izvēlnē “Attālā replikācija” atlasiet mūsu savienojumu REPL1 un noklikšķiniet uz “Mainīt lomu”.
Pēc dažām sekundēm LUN1R (rezerves krātuves sistēma) kļūst par primāro.
Mēs kartējam LUN1R ar uzglabāšanas sistēmu2.
Pēc tam mūsu E: disks tiek automātiski pievienots saimniekdatoram, tikai šoreiz tas “atnāca” no LUN1R.
Katram gadījumam mēs salīdzinām hash summas.
Identiski. Pārbaude nokārtota.
Kļūmjpārlēce. Datu centra kļūme
Šobrīd galvenā uzglabāšanas sistēma pēc regulāras pārslēgšanas ir attiecīgi uzglabāšanas sistēma 2 un LUN1R. Lai līdzinātos negadījumam, mēs izslēgsim strāvu abiem krātuves kontrolleriem2.
Tam vairs nav piekļuves.
Apskatīsim, kas notiek 1. glabāšanas sistēmā (šobrīd rezerves sistēmā).
Mēs redzam, ka primārais LUN (LUN1R) nav pieejams. Kļūdas ziņojums parādījās žurnālos, informācijas panelī un arī pašā replikācijas noteikumā. Attiecīgi dati no saimniekdatora pašlaik nav pieejami.
Mainiet LUN1 lomu uz Primārā.
Es veicu kartēšanu saimniekam.
Pārliecinieties, vai resursdatorā ir redzams disks E.
Mēs pārbaudām hash.
Viss ir kārtībā. Uzglabāšanas sistēma veiksmīgi pārdzīvoja datu centra krišanu, kas darbojās. Aptuvenais laiks, ko pavadījām, lai izveidotu savienojumu ar replikācijas “apvērstu” un LUN savienojumu no rezerves datu centra, bija aptuveni 3 minūtes. Ir skaidrs, ka reālajā ražošanā viss ir daudz sarežģītāk, un papildus darbībām ar uzglabāšanas sistēmām jums ir jāveic daudz vairāk darbību tīklā, resursdatoros, lietojumprogrammās. Un dzīvē šis laika posms būs daudz ilgāks.
Šeit es gribētu rakstīt, ka viss, tests ir veiksmīgi izpildīts, bet nesteigsimies. Galvenā uzglabāšanas sistēma ir “melo”, mēs zinām, ka tad, kad tā “nokrita”, tā bija primārajā lomā. Kas notiek, ja tas pēkšņi ieslēdzas? Būs divas galvenās lomas, kas ir vienāda ar datu sabojāšanu? Tagad pārbaudīsim.
Pēkšņi ieslēgsim pamatā esošo krātuves sistēmu.
Tas tiek ielādēts dažas minūtes un pēc īsas sinhronizācijas atgriežas darbā, bet sekundārā lomā.
Viss OK. Split-smadzeņu nenotika. Mēs par to domājām, un vienmēr pēc kritiena uzglabāšanas sistēma kļūst par sekundāro lomu neatkarīgi no tā, kāda loma tai bija “dzīves laikā”. Tagad mēs varam droši teikt, ka datu centra atteices pārbaude bija veiksmīga.
Sakaru kanālu atteice starp datu centriem
Šī testa galvenais uzdevums ir pārliecināties, ka uzglabāšanas sistēma nesāk darboties dīvaini, ja tā īslaicīgi pazaudē sakaru kanālus starp divām uzglabāšanas sistēmām un pēc tam parādās vēlreiz.
Tātad. Atvienojam vadus starp uzglabāšanas sistēmām (iedomāsimies, ka tos izraka ekskavators).
Sākumskolā mēs redzam, ka nav nekāda sakara ar sekundāro.
Vidusskolā mēs redzam, ka nav nekāda sakara ar primāro.
Viss darbojas labi, un mēs turpinām rakstīt datus galvenajā krātuves sistēmā, tas ir, tie garantēti atšķiras no rezerves, tas ir, tie ir “atdalīti”.
Dažu minūšu laikā mēs “salabojam” sakaru kanālu. Tiklīdz uzglabāšanas sistēmas saskata viena otru, automātiski tiek aktivizēta datu sinhronizācija. Šeit no administratora nekas netiek prasīts.
Pēc kāda laika sinhronizācija ir pabeigta.
Savienojums tika atjaunots, sakaru kanālu zudums neradīja avārijas situācijas, un pēc ieslēgšanas sinhronizācija notika automātiski.
Atzinumi
Mēs analizējām teoriju - kas ir vajadzīgs un kāpēc, kur ir plusi un kur ir mīnusi. Pēc tam mēs iestatām sinhrono replikāciju starp divām uzglabāšanas sistēmām.
Pēc tam tika veikti pamata testi normālai pārslēgšanai, datu centra kļūmei un sakaru kanāla kļūmei. Visos gadījumos uzglabāšanas sistēma darbojās labi. Netiek zaudēti dati, un manuālā scenārija gadījumā administratīvās darbības tiek samazinātas līdz minimumam.
Nākamreiz sarežģīsim situāciju un parādīsim, kā visa šī loģika darbojas automatizētā metroklasterā aktīvajā-aktīvajā režīmā, tas ir, kad primārās ir abas glabāšanas sistēmas un uzvedība uzglabāšanas sistēmas kļūmju gadījumā ir pilnībā automatizēta.
Lūdzu, rakstiet komentārus, mēs priecāsimies saņemt pamatotu kritiku un praktiskus padomus.
Līdz nākamajai reizei.
Avots: www.habr.com