Hei Habr-lukijat! Tämän artikkelin aiheena on katastrofipalautustyökalujen käyttöönotto AERODISK Enginen tallennusjärjestelmissä. Aluksi halusimme kirjoittaa yhdessä artikkelissa molemmista työkaluista: replikaatiosta ja metroklusterista, mutta valitettavasti artikkeli osoittautui liian pitkäksi, joten jaoimme artikkelin kahteen osaan. Siirrytään yksinkertaisesta monimutkaiseen. Tässä artikkelissa määritämme ja testaamme synkronista replikointia - hylkäämme yhden datakeskuksen ja katkaisemme myös tietokeskusten välisen tietoliikennekanavan ja katsomme mitä tapahtuu.
Asiakkaamme kysyvät meiltä usein erilaisia replikointiin liittyviä kysymyksiä, joten ennen kuin siirrymme replikoiden käyttöönottoon ja testaamiseen, kerromme sinulle hieman siitä, mitä replikointi tallennustilassa on.
Hieman teoria
Replikointi tallennusjärjestelmissä on jatkuva prosessi, jolla varmistetaan tietojen identiteetti useissa tallennusjärjestelmissä samanaikaisesti. Teknisesti replikointi suoritetaan kahdella tavalla.
Synkroninen replikointi – tämä on tietojen kopiointi päätallennusjärjestelmästä varmistusjärjestelmään, minkä jälkeen molemmilta tallennusjärjestelmiltä vaaditaan vahvistus, että tiedot on tallennettu ja vahvistettu. Kun molemmat osapuolet (molemmat tallennusjärjestelmät) ovat vahvistaneet, tiedot katsotaan tallennetuiksi ja niitä voidaan käsitellä. Tämä varmistaa taatun tietojen identiteetin kaikissa replikaan osallistuvissa tallennusjärjestelmissä.
Tämän menetelmän edut:
- Tiedot ovat aina identtisiä kaikissa tallennusjärjestelmissä
Miinukset:
- Ratkaisun korkea hinta (nopeat viestintäkanavat, kallis optinen kuitu, pitkäaaltolähetin-vastaanottimet jne.)
- Etäisyysrajoitukset (useiden kymmenien kilometrien sisällä)
- Ei ole suojaa loogisten tietojen korruptoitumista vastaan (jos tiedot vioituvat (tahallisesti tai vahingossa) päätallennusjärjestelmässä, ne vioituvat automaattisesti ja välittömästi varmuuskopiojärjestelmässä, koska tiedot ovat aina identtisiä (se on paradoksi)
Asynkroninen replikointi – tämä on myös tietojen kopiointia päätallennusjärjestelmästä varmuuskopioon, mutta tietyllä viiveellä ja ilman tarvetta vahvistaa kirjoitusta toisella puolella. Voit työskennellä tietojen kanssa heti sen jälkeen, kun ne on tallennettu päätallennusjärjestelmään, ja varatallennusjärjestelmässä tiedot ovat käytettävissä jonkin ajan kuluttua. Tietojen identiteettiä ei tässä tapauksessa tietenkään taata ollenkaan. Varmistustallennusjärjestelmän tiedot ovat aina hieman "menneisyydessä".
Asynkronisen replikoinnin edut:
- Edullinen ratkaisu (kaikki viestintäkanavat, optiikka valinnainen)
- Ei etäisyysrajoituksia
- Varmistustallennusjärjestelmässä tiedot eivät heikkene, jos ne ovat vaurioituneet pääjärjestelmässä (ainakin jonkin aikaa); jos tiedot vioituvat, voit aina pysäyttää replikan estääksesi tietojen korruption varatallennusjärjestelmässä
Miinukset:
- Eri datakeskusten tiedot eivät aina ole identtisiä
Näin ollen replikointitilan valinta riippuu liiketoiminnan tavoitteista. Jos sinulle on tärkeää, että varmuuskopiointipalvelinkeskus sisältää täsmälleen samat tiedot kuin pääpalvelinkeskus (eli liiketoiminnan vaatimus RPO:lle = 0), sinun on otettava käteisvaroja pois ja siedettävä synkronisen datakeskuksen rajoituksia. kopio. Ja jos viive datatilassa on hyväksyttävä tai rahaa ei yksinkertaisesti ole, sinun on ehdottomasti käytettävä asynkronista menetelmää.
Korostetaan erikseen myös sellainen tila (tarkemmin topologia) kuten metroklusteri. Metroklusteritilassa käytetään synkronista replikointia, mutta toisin kuin tavallinen replika, metroklusteri sallii molempien tallennusjärjestelmien toimia aktiivisessa tilassa. Nuo. sinulla ei ole eroa aktiivisen ja valmiustilassa olevan datakeskuksen välillä. Sovellukset toimivat samanaikaisesti kahden tallennusjärjestelmän kanssa, jotka sijaitsevat fyysisesti eri tietokeskuksissa. Seisokit onnettomuudessa tällaisessa topologiassa ovat hyvin pieniä (RTO, yleensä minuuttia). Tässä artikkelissa emme käsittele metroklusterin toteutusta, koska tämä on erittäin laaja ja tilava aihe, joten omistamme sille erillisen, seuraavan artikkelin tämän jatkoksi.
Myös hyvin usein, kun puhumme replikoinnista tallennusjärjestelmien avulla, monilla ihmisillä on aiheellinen kysymys: > "Monilla sovelluksilla on omat replikointityökalunsa, miksi käyttää replikointia tallennusjärjestelmissä? Onko se parempi vai huonompi?
Tässä ei ole selkeää vastausta, joten tässä on argumentit PUOLELLE ja MIINUKSET:
Argumentit tallennuksen replikaatiolle:
- Ratkaisun yksinkertaisuus. Yhdellä työkalulla voit kopioida koko tietojoukon kuormitustyypistä ja sovelluksesta riippumatta. Jos käytät kopiota sovelluksista, sinun on määritettävä jokainen sovellus erikseen. Jos niitä on enemmän kuin 2, tämä on erittäin työvoimavaltaista ja kallista (sovelluksen replikointi vaatii yleensä erillisen, ei ilmaisen lisenssin jokaiselle sovellukselle. Mutta siitä lisää alla).
- Voit kopioida mitä tahansa - mitä tahansa sovellusta, mitä tahansa dataa - ja se on aina johdonmukainen. Monilla (useimmilla) sovelluksilla ei ole replikointiominaisuuksia, ja tallennusjärjestelmän kopiot ovat ainoa tapa suojata katastrofeja vastaan.
- Sovelluksen replikointitoiminnasta ei tarvitse maksaa liikaa. Pääsääntöisesti se ei ole halpaa, aivan kuten tallennusjärjestelmän replikan lisenssit. Mutta sinun on maksettava tallennustilan replikoinnin lisenssi kerran, ja sovelluksen replikan lisenssi on ostettava jokaiselle sovellukselle erikseen. Jos tällaisia sovelluksia on paljon, se maksaa melkoisen pennin ja tallennustilan replikoinnin lisenssien kustannukset ovat pisara meressä.
Argumentit tallennuksen replikaatiota VASTAISET:
- Replikalla sovellusten kautta on enemmän toimivuutta itse sovellusten kannalta, sovellus tuntee tietonsa paremmin (ilmeisesti), joten niiden kanssa työskentelyyn on enemmän vaihtoehtoja.
- Joidenkin sovellusten valmistajat eivät takaa tietojensa johdonmukaisuutta, jos replikointi suoritetaan kolmannen osapuolen työkaluilla. *
* - kiistanalainen opinnäytetyö. Esimerkiksi tunnettu DBMS-valmistaja on virallisesti julistanut hyvin pitkään, että heidän DBMS-järjestelmänsä voidaan replikoida normaalisti vain heidän keinoillaan, ja muu replikointi (mukaan lukien tallennusjärjestelmät) ei ole totta. Mutta elämä on osoittanut, että näin ei ole. Todennäköisesti (mutta tämä ei ole varmaa) tämä ei yksinkertaisesti ole rehellisin yritys myydä lisää lisenssejä asiakkaille.
Tämän seurauksena useimmissa tapauksissa replikointi tallennusjärjestelmästä on parempi, koska Tämä on yksinkertaisempi ja halvempi vaihtoehto, mutta on monimutkaisia tapauksia, joissa tarvitaan erityisiä sovellustoimintoja ja on tarpeen työskennellä sovellustason replikoinnin kanssa.
Teoria loppu, nyt käytäntö
Määritämme replikan laboratoriossamme. Laboratorio-olosuhteissa emuloimme kahta datakeskusta (itse asiassa kahta vierekkäistä telinettä, jotka näyttivät olevan eri rakennuksissa). Teline koostuu kahdesta Engine N2 -säilytysjärjestelmästä, jotka on yhdistetty toisiinsa optisilla kaapeleilla. Fyysinen Windows Server 2016 -palvelin on yhdistetty molempiin tallennusjärjestelmiin 10 Gt Ethernetin avulla. Teline on melko yksinkertainen, mutta tämä ei muuta olemusta.
Kaavamaisesti se näyttää tältä:
Loogisesti replikointi on järjestetty seuraavasti:
Katsotaanpa nyt käytössämme olevaa replikointitoimintoa.
Kaksi tilaa tuetaan: asynkroninen ja synkroninen. On loogista, että synkronista tilaa rajoittavat etäisyys ja viestintäkanava. Erityisesti synkroninen tila vaatii kuitujen käyttöä fysiikan ja 10 Gigabit Ethernetin (tai uudemman) käyttöä.
Synkronisen replikoinnin tuettu etäisyys on 40 kilometriä, datakeskusten välisen optisen kanavan viivearvo on jopa 2 millisekuntia. Yleensä se toimii suurilla viiveillä, mutta sitten tulee voimakkaita hidastuksia tallennuksen aikana (mikä on myös loogista), joten jos suunnittelet synkronista replikointia datakeskusten välillä, kannattaa tarkistaa optiikan laatu ja viiveet.
Asynkronisen replikoinnin vaatimukset eivät ole niin vakavia. Tarkemmin sanottuna niitä ei ole ollenkaan. Mikä tahansa toimiva Ethernet-yhteys käy.
Tällä hetkellä AERODISK ENGINE -tallennusjärjestelmä tukee lohkolaitteiden (LUN:iden) replikointia Ethernet-protokollan kautta (kuparin tai optisen kautta). Projekteihin, joissa tarvitaan replikointia SAN-kankaan kautta kuitukanavan kautta, lisäämme parhaillaan sopivaa ratkaisua, mutta se ei ole vielä valmis, joten meidän tapauksessamme vain Ethernet.
Replikointi voi toimia minkä tahansa ENGINE-sarjan tallennusjärjestelmien (N1, N2, N4) välillä juniorijärjestelmistä vanhempiin ja päinvastoin.
Molempien replikointitilojen toiminnallisuus on täysin identtinen. Alla on lisätietoja siitä, mitä on saatavilla:
- Replikointi "yksi yhteen" tai "yksi yhteen", eli klassinen versio, jossa on kaksi datakeskusta, pää- ja varmuuskopio
- Replikointi on "yksi moniin" tai "yksi moniin", ts. yksi LUN voidaan kopioida useaan tallennusjärjestelmään kerralla
- Aktivoi, deaktivoi ja "käännä" replikointi, ottaaksesi käyttöön, poistaaksesi käytöstä tai muuttaaksesi replikoinnin suuntaa
- Replikointi on saatavilla sekä RDG (Raid Distributed Group) että DDP (Dynamic Disk Pool) -poolille. RDG-poolin LUN-tunnukset voidaan kuitenkin replikoida vain toiseen RDG:hen. Sama DDP:n kanssa.
Pieniä ominaisuuksia on monia muitakin, mutta niiden luettelemisessa ei ole erityistä järkeä; mainitsemme ne asennuksen yhteydessä.
Asetetaan replikointi
Asennusprosessi on melko yksinkertainen ja koostuu kolmesta vaiheesta.
- Verkon asetukset
- Tallennustilan asetukset
- Sääntöjen (yhteyksien) asettaminen ja kartoitus
Tärkeä kohta replikoinnin asettamisessa on, että kaksi ensimmäistä vaihetta tulee toistaa etätallennusjärjestelmässä, kolmas vaihe - vain pääjärjestelmässä.
Verkkoresurssien määrittäminen
Ensimmäinen vaihe on määrittää verkkoportit, joiden kautta replikointiliikenne siirretään. Tätä varten sinun on otettava portit käyttöön ja asetettava niiden IP-osoitteet Käyttöliittymäsovittimet-osiossa.
Tämän jälkeen meidän on luotava pooli (tapauksessamme RDG) ja virtuaalinen IP replikointia varten (VIP). VIP on kelluva IP-osoite, joka on sidottu kahteen tallennusohjainten "fyysiseen" osoitteeseen (juuri määrittämämme portit). Tämä on tärkein replikointirajapinta. Voit myös toimia ei VIP:n, vaan VLAN:in kanssa, jos sinun on työskenneltävä tunnistetun liikenteen kanssa.
Replikan VIP:n luominen ei juurikaan eroa VIP:n luomisesta I/O:lle (NFS, SMB, iSCSI). Tässä tapauksessa luomme tavallisen VIP:n (ilman VLAN:ia), mutta muista ilmoittaa, että se on tarkoitettu replikointiin (ilman tätä osoitinta emme voi lisätä VIP:tä sääntöön seuraavassa vaiheessa).
VIP:n on oltava samassa aliverkossa kuin IP-portit, joiden välillä se kelluu.
Toistamme nämä asetukset etätallennusjärjestelmässä, tietysti eri IP-osoitteella.
VIPit eri tallennusjärjestelmistä voivat olla eri aliverkoissa, pääasia, että niiden välillä on reititys. Meidän tapauksessamme tämä esimerkki näkyy tarkasti (192.168.3.XX ja 192.168.2.XX)
Tämä päättää verkko-osan valmistelun.
Tallennustilan määrittäminen
Replikan tallennustilan määrittäminen eroaa tavallisesta vain siinä, että teemme kartoituksen erityisen valikon ”Replikointikartoitus” kautta. Muuten kaikki on sama kuin normaalissa asetelmassa. Nyt järjestyksessä.
Aiemmin luodussa poolissa R02 sinun on luotava LUN. Luodaan se ja kutsumme sitä LUN1:ksi.
Meidän on myös luotava sama LUN samankokoiseen etätallennusjärjestelmään. Me luomme. Sekaannusten välttämiseksi soitetaan kauko-ohjain LUN LUN1R
Jos meidän piti ottaa jo olemassa oleva LUN, replikaa määritettäessä meidän on irrotettava tämä tuottava LUN isännästä ja luotava yksinkertaisesti samankokoinen tyhjä LUN etätallennusjärjestelmään.
Tallennusasetukset on valmis, siirrytään replikointisäännön luomiseen.
Replikointisääntöjen tai replikointilinkkien määrittäminen
Kun olet luonut LUN-tunnukset tallennusjärjestelmään, joka on tällä hetkellä ensisijainen, määritämme replikointisäännön LUN1 tallennusjärjestelmässä 1 ja LUN1R tallennusjärjestelmässä 2.
Asetus tehdään "Etäkopiointi" -valikosta
Luodaan sääntö. Tätä varten sinun on määritettävä replikan vastaanottaja. Siellä asetetaan myös yhteyden nimi ja replikaation tyyppi (synkroninen tai asynkroninen).
"Etäjärjestelmät"-kenttään lisäämme tallennusjärjestelmämme2. Lisätäksesi sinun on käytettävä hallinta-IP-tallennusjärjestelmiä (MGR) ja etä-LUN:n nimeä, johon teemme replikoinnin (tässä tapauksessa LUN1R). Ohjaus-IP:itä tarvitaan vain yhteyden lisäysvaiheessa, replikointiliikennettä ei välitetä niiden kautta, vaan tähän käytetään aiemmin määritettyä VIP-osoitetta.
Jo tässä vaiheessa voimme lisätä useamman kuin yhden etäjärjestelmän "yhdestä moneen" -topologiaan: napsauta "lisää solmu" -painiketta, kuten alla olevassa kuvassa.
Meidän tapauksessamme on vain yksi etäjärjestelmä, joten rajoitamme vain tähän.
Sääntö on valmis. Huomaa, että se lisätään automaattisesti kaikille replikaation osallistujille (meidän tapauksessamme niitä on kaksi). Voit luoda niin monta sääntöjä kuin haluat, mille tahansa LUN-määrälle ja mihin tahansa suuntaan. Esimerkiksi kuorman tasapainottamiseksi voimme replikoida osan LUN:ista tallennusjärjestelmästä 1 tallennusjärjestelmään 2 ja toisen osan, päinvastoin, tallennusjärjestelmästä 2 tallennusjärjestelmään 1.
Varastointijärjestelmä 1. Synkronointi alkoi heti luomisen jälkeen.
Varastointijärjestelmä 2. Näemme saman säännön, mutta synkronointi on jo päättynyt.
Tallennusjärjestelmän 1 LUN1 on ensisijaisessa roolissa, eli se on aktiivinen. Tallennusjärjestelmän 1 LUN2R on toissijaisessa roolissa, eli se on valmiustilassa, jos tallennusjärjestelmä 1 epäonnistuu.
Nyt voimme yhdistää LUN:n isäntään.
Yhdistämme iSCSI:n kautta, vaikka se voidaan tehdä myös FC:n kautta. Kartoituksen määrittäminen iSCSI LUNin kautta replikassa ei käytännössä eroa tavallisesta skenaariosta, joten emme käsittele tätä tässä yksityiskohtaisesti. Jos jotain, tämä prosessi on kuvattu artikkelissa "'.
Ainoa ero on, että luomme kartoituksen "Replication Mapping" -valikossa
Asetimme kartoituksen ja annoimme LUN:n isännälle. Isäntä näki LUN:n.
Alustamme sen paikalliseen tiedostojärjestelmään.
Siinä kaikki, asennus on valmis. Testit tulee seuraavaksi.
Testaus
Testaamme kolmea pääskenaariota.
- Säännöllinen roolin vaihto Toissijainen > Ensisijainen. Säännöllinen roolinvaihto on tarpeen siinä tapauksessa, että joudumme esimerkiksi suorittamaan ennaltaehkäiseviä toimintoja pääkonekeskuksessa ja tänä aikana siirrämme kuorman varatietokeskukseen, jotta tiedot olisivat saatavilla.
- Hätäroolin vaihto Toissijainen > Ensisijainen (tietokeskuksen vika). Tämä on replikoinnin pääskenaario, joka voi auttaa selviytymään täydellisestä palvelinkeskuksen epäonnistumisesta pysäyttämättä yritystä pitkäksi aikaa.
- Viestintäkanavien erittely datakeskusten välillä. Kahden tallennusjärjestelmän oikean toiminnan tarkistaminen olosuhteissa, joissa tietokeskusten välinen viestintäkanava ei jostain syystä ole käytettävissä (esim. kaivinkone kaivettiin väärään paikkaan ja rikkoi tumman optiikan).
Ensin aloitamme tietojen kirjoittamisen LUN:iin (tiedostojen kirjoittaminen satunnaisilla tiedoilla). Näemme heti, että tallennusjärjestelmien välistä viestintäkanavaa hyödynnetään. Tämä on helppo ymmärtää, jos avaat replikaatiosta vastaavien porttien kuormituksen valvonnan.
Molemmissa tallennusjärjestelmissä on nyt "hyödyllistä" tietoa, voimme aloittaa testin.
Katsotaanpa vain varmuuden vuoksi jonkin tiedoston hash-summia ja kirjoitetaan ne muistiin.
Säännöllinen roolinvaihto
Roolien vaihtaminen (replikoinnin suunnan muuttaminen) voidaan tehdä millä tahansa tallennusjärjestelmällä, mutta sinun on silti siirryttävä molempiin, koska sinun on poistettava kartoitus käytöstä ensisijaisessa ja otettava se käyttöön toissijaisessa (josta tulee ensisijainen). ).
Ehkä nyt herää järkevä kysymys: miksi ei automatisoida tätä? Vastaus on: se on yksinkertainen, replikointi on yksinkertainen tapa parantaa katastrofien kestoa, joka perustuu yksinomaan manuaalisiin toimintoihin. Näiden toimintojen automatisoimiseksi on olemassa metroklusteritila; se on täysin automatisoitu, mutta sen konfigurointi on paljon monimutkaisempi. Kirjoitamme metroklusterin perustamisesta seuraavassa artikkelissa.
Päätallennusjärjestelmässä poistamme kartoituksen käytöstä varmistaaksemme, että tallennus pysähtyy.
Valitse sitten jossakin tallennusjärjestelmässä (ei väliä, pää- tai varmuuskopiossa) "Etäreplikointi" -valikosta yhteytemme REPL1 ja napsauta "Vaihda roolia".
Muutaman sekunnin kuluttua LUN1R (varamuistijärjestelmä) muuttuu ensisijaiseksi.
Kartoitamme LUN1R:n tallennusjärjestelmällä2.
Tämän jälkeen E:-asemamme liitetään automaattisesti isäntään, vain tällä kertaa se "saapui" LUN1R:stä.
Varmuuden vuoksi vertaamme hash-summia.
Identtisesti. Koe läpäisty.
Failover. Datakeskuksen vika
Tällä hetkellä päämuistijärjestelmä säännöllisen vaihdon jälkeen on vastaavasti tallennusjärjestelmä 2 ja LUN1R. Onnettomuuden jäljittelemiseksi katkaisemme virran molemmista tallennusohjaimista2.
Siihen ei ole enää pääsyä.
Katsotaan mitä tapahtuu tallennusjärjestelmässä 1 (tällä hetkellä varmuuskopiojärjestelmä).
Näemme, että ensisijainen LUN (LUN1R) ei ole käytettävissä. Virheilmoitus ilmestyi lokeihin, tietopaneeliin ja myös itse replikointisääntöön. Näin ollen tiedot isännältä eivät ole tällä hetkellä saatavilla.
Muuta LUN1:n rooliksi Ensisijainen.
Teen kartoituksen isännille.
Varmista, että asema E näkyy isännässä.
Tarkistamme hashin.
Kaikki on hyvin. Tallennusjärjestelmä selviytyi onnistuneesti aktiivisen datakeskuksen romahtamisesta. Arvioitu aika, jonka käytimme replikaation "käänteisen" yhdistämiseen ja LUN:n yhdistämiseen varatietokeskuksesta, oli noin 3 minuuttia. On selvää, että todellisessa tuotannossa kaikki on paljon monimutkaisempaa, ja tallennusjärjestelmien kanssa suoritettavien toimien lisäksi sinun on suoritettava paljon enemmän toimintoja verkossa, isännissä, sovelluksissa. Ja elämässä tämä aika on paljon pidempi.
Tänne haluaisin kirjoittaa, että kaikki, testi on suoritettu onnistuneesti, mutta älkäämme kiirehtikö. Päävarastojärjestelmä "makaa", tiedämme, että kun se "pudotti", se oli ensisijaisessa roolissa. Mitä tapahtuu, jos se yhtäkkiä syttyy? Tulee kaksi ensisijaista roolia, mikä vastaa tietojen korruptiota? Tarkastetaan nyt.
Kytketään yhtäkkiä päälle taustalla oleva tallennusjärjestelmä.
Se latautuu muutaman minuutin ja palaa sitten palveluun lyhyen synkronoinnin jälkeen, mutta toissijaisena.
Kaikki hyvin. Aivojen jakautuminen ei tapahtunut. Ajattelimme tätä, ja aina kaatumisen jälkeen säilytysjärjestelmä nousee Toissijaisen rooliin, riippumatta siitä, mikä rooli sillä oli "elämän aikana". Nyt voimme varmuudella sanoa, että datakeskuksen vikatesti onnistui.
Tietokeskusten välisten viestintäkanavien epäonnistuminen
Tämän testin päätehtävänä on varmistaa, että tallennusjärjestelmä ei ala käyttäytymään oudosti, jos se väliaikaisesti menettää kahden tallennusjärjestelmän väliset viestintäkanavat ja ilmestyy sitten uudelleen.
Niin. Irrotamme johdot varastojärjestelmien välillä (kuvitellaan, että ne kaivoi kaivinkoneella).
Alkeisluokissa näemme, että toissijaiseen ei ole yhteyttä.
Toissijaisessa oppilaitoksessa näemme, että Alkeisyhdistykseen ei ole yhteyttä.
Kaikki toimii hyvin, ja jatkamme tietojen kirjoittamista päätallennusjärjestelmään, eli ne taatusti eroavat varmuuskopiosta, eli ne ovat "erottuneet".
Muutamassa minuutissa "korjaamme" viestintäkanavan. Heti kun tallennusjärjestelmät näkevät toisensa, tietojen synkronointi aktivoituu automaattisesti. Täällä ei vaadita ylläpitäjältä mitään.
Jonkin ajan kuluttua synkronointi on valmis.
Yhteys palautui, viestintäkanavien katoaminen ei aiheuttanut hätätilanteita ja päällekytkennän jälkeen synkronointi tapahtui automaattisesti.
Tulokset
Analysoimme teoriaa - mitä tarvitaan ja miksi, missä on plussat ja missä haitat. Sitten määritämme synkronisen replikoinnin kahden tallennusjärjestelmän välille.
Seuraavaksi suoritettiin perustestit normaalin kytkennän, konesalin vian ja tietoliikennekanavavian varalta. Kaikissa tapauksissa säilytysjärjestelmä toimi hyvin. Tietoa ei häviä, ja hallinnolliset toiminnot on minimoitu manuaalisessa skenaariossa.
Seuraavalla kerralla monimutkaistamme tilannetta ja näytämme kuinka tämä kaikki logiikka toimii automatisoidussa metroklusterissa aktiivi-aktiivisessa tilassa, eli kun molemmat tallennusjärjestelmät ovat ensisijaisia ja käyttäytyminen tallennusjärjestelmän vikojen sattuessa on täysin automatisoitua.
Kirjoita kommentteja, otamme mielellämme hyvää kritiikkiä ja käytännön neuvoja.
Ensi kertaan.
Lähde: will.com