Hallo Habr-lezers! Het onderwerp van dit artikel is de implementatie van tools voor noodherstel in AERODISK Engine-opslagsystemen. Aanvankelijk wilden we in één artikel over beide tools schrijven: replicatie en metrocluster, maar helaas bleek het artikel te lang te zijn, dus hebben we het artikel in twee delen verdeeld. Laten we van eenvoudig naar complex gaan. In dit artikel zullen we synchrone replicatie opzetten en testen - we zullen één datacenter laten vallen, en ook het communicatiekanaal tussen de datacenters verbreken en kijken wat er gebeurt.
Onze klanten stellen ons vaak verschillende vragen over replicatie, dus voordat we verder gaan met het opzetten en testen van de implementatie van replica's, zullen we u eerst iets vertellen over wat replicatie in opslag is.
Een beetje theorie
Replicatie in opslagsystemen is een continu proces waarbij de gegevensidentiteit op meerdere opslagsystemen tegelijkertijd wordt gewaarborgd. Technisch gezien wordt replicatie op twee manieren bereikt.
Synchrone replicatie – dit is het kopiëren van gegevens van het hoofdopslagsysteem naar het back-upsysteem, gevolgd door een verplichte bevestiging van beide opslagsystemen dat de gegevens zijn vastgelegd en bevestigd. Pas na bevestiging aan beide kanten (beide opslagsystemen) worden de gegevens als vastgelegd beschouwd en kan er mee worden gewerkt. Dit garandeert een gegarandeerde gegevensidentiteit op alle opslagsystemen die aan de replica deelnemen.
De voordelen van deze methode:
- Gegevens zijn altijd identiek op alle opslagsystemen
Tegens:
- Hoge kosten van de oplossing (snelle communicatiekanalen, dure optische vezels, langegolfzendontvangers, enz.)
- Afstandsbeperkingen (binnen enkele tientallen kilometers)
- Er is geen bescherming tegen corruptie van logische gegevens (als gegevens beschadigd raken (opzettelijk of per ongeluk) op het hoofdopslagsysteem, zullen deze automatisch en onmiddellijk beschadigd raken op het back-upsysteem, aangezien de gegevens altijd identiek zijn (dat is de paradox)
Asynchrone replicatie – dit is ook het kopiëren van gegevens van het hoofdopslagsysteem naar het back-upsysteem, maar met een bepaalde vertraging en zonder de noodzaak om het schrijven aan de andere kant te bevestigen. U kunt direct met de gegevens werken nadat u deze op het hoofdopslagsysteem hebt opgeslagen, en op het back-upopslagsysteem zullen de gegevens na enige tijd beschikbaar zijn. De identiteit van de gegevens is in dit geval uiteraard helemaal niet gegarandeerd. De gegevens op het back-upopslagsysteem bevinden zich altijd een beetje ‘in het verleden’.
Voordelen van asynchrone replicatie:
- Goedkope oplossing (alle communicatiekanalen, optica optioneel)
- Geen afstandsbeperkingen
- Op het back-upopslagsysteem gaan de gegevens niet achteruit als deze beschadigd raken op het hoofdsysteem (tenminste voor enige tijd); als de gegevens beschadigd raken, kunt u de replica altijd stoppen om gegevensbeschadiging op het back-upopslagsysteem te voorkomen
Tegens:
- Data in verschillende datacenters zijn niet altijd identiek
De keuze voor de replicatiemodus hangt dus af van de bedrijfsdoelstellingen. Als het voor u van cruciaal belang is dat het back-updatacenter exact dezelfde gegevens bevat als het hoofddatacenter (d.w.z. bedrijfsvereiste voor RPO = 0), dan zult u het geld moeten opbrengen en de beperkingen van een synchrone datacenter moeten accepteren. replica. En als de vertraging in de gegevensstatus acceptabel is of als er simpelweg geen geld is, dan moet je zeker de asynchrone methode gebruiken.
Laten we een dergelijke modus (meer precies, een topologie) ook afzonderlijk benadrukken als een metrocluster. In de metroclustermodus wordt gebruik gemaakt van synchrone replicatie, maar in tegenstelling tot een gewone replica zorgt een metrocluster ervoor dat beide opslagsystemen in de actieve modus kunnen werken. Die. er is geen scheiding tussen actieve en stand-by datacenters. Applicaties werken gelijktijdig met twee opslagsystemen, die zich fysiek in verschillende datacenters bevinden. De stilstandtijden tijdens ongevallen zijn in een dergelijke topologie zeer klein (RTO, meestal minuten). In dit artikel zullen we onze implementatie van de metrocluster niet beschouwen, aangezien dit een zeer groot en uitgebreid onderwerp is, dus zullen we er een apart volgend artikel aan wijden, als vervolg op dit artikel.
Als we het hebben over replicatie met behulp van opslagsystemen, hebben veel mensen ook vaak een redelijke vraag: > “Veel applicaties hebben hun eigen replicatietools, waarom zouden we replicatie op opslagsystemen gebruiken? Is het beter of slechter?
Er is hier geen duidelijk antwoord, dus hier zijn de argumenten VOOR en CONS:
Argumenten VOOR opslagreplicatie:
- Eenvoud van de oplossing. Met één tool kunt u uw volledige dataset repliceren, ongeacht het belastingstype en de toepassing. Als u een replica van applicaties gebruikt, moet u elke applicatie afzonderlijk configureren. Als het er meer dan 2 zijn, dan is dit extreem arbeidsintensief en duur (voor applicatiereplicatie is doorgaans voor elke applicatie een aparte en niet gratis licentie nodig. Maar daarover hieronder meer).
- Je kunt alles repliceren – elke applicatie, elke data – en het zal altijd consistent zijn. Veel (de meeste) applicaties beschikken niet over replicatiemogelijkheden, en replica's van het opslagsysteem zijn de enige manier om bescherming te bieden tegen rampen.
- Het is niet nodig om te veel te betalen voor de replicatiefunctionaliteit van applicaties. In de regel is het niet goedkoop, net als licenties voor een replica van een opslagsysteem. Maar u moet eenmalig betalen voor een licentie voor opslagreplicatie, en een licentie voor applicatiereplica moet voor elke applicatie afzonderlijk worden aangeschaft. Als er veel van dergelijke toepassingen zijn, kost het een aardige cent en worden de kosten van licenties voor opslagreplicatie een druppel op een gloeiende plaat.
Argumenten TEGEN opslagreplicatie:
- Replica via applicaties heeft meer functionaliteit vanuit het oogpunt van de applicaties zelf, de applicatie kent zijn data (uiteraard) beter, dus er zijn meer mogelijkheden om ermee te werken.
- Fabrikanten van sommige applicaties kunnen de consistentie van hun gegevens niet garanderen als replicatie wordt uitgevoerd met behulp van tools van derden. *
* - controversieel proefschrift. Een bekende DBMS-fabrikant heeft bijvoorbeeld al heel lang officieel verklaard dat hun DBMS alleen normaal kan worden gerepliceerd met behulp van hun middelen, en dat de rest van de replicatie (inclusief opslagsystemen) ‘niet waar’ is. Maar het leven heeft aangetoond dat dit niet zo is. Hoogstwaarschijnlijk (maar dit is niet zeker) is dit simpelweg niet de meest eerlijke poging om meer licenties aan klanten te verkopen.
Als gevolg hiervan is replicatie vanuit het opslagsysteem in de meeste gevallen beter Dit is een eenvoudiger en goedkopere optie, maar er zijn complexe gevallen waarin specifieke applicatiefunctionaliteit nodig is en het noodzakelijk is om met replicatie op applicatieniveau te werken.
Klaar met theorie, nu praktijk
We zullen de replica in ons laboratorium configureren. In laboratoriumomstandigheden hebben we twee datacenters nagebootst (in feite twee aangrenzende racks die zich in verschillende gebouwen leken te bevinden). De stand bestaat uit twee Engine N2 opslagsystemen, die door middel van optische kabels met elkaar zijn verbonden. Een fysieke server met Windows Server 2016 is met beide opslagsystemen verbonden via 10Gb Ethernet. De standaard is vrij eenvoudig, maar dit verandert niets aan de essentie.
Schematisch ziet het er als volgt uit:
Logischerwijs is de replicatie als volgt georganiseerd:
Laten we nu eens kijken naar de replicatiefunctionaliteit die we nu hebben.
Er worden twee modi ondersteund: asynchroon en synchroon. Het is logisch dat de synchrone modus wordt beperkt door afstand en communicatiekanaal. In het bijzonder vereist de synchrone modus het gebruik van glasvezel als fysica en 10 Gigabit Ethernet (of hoger).
De ondersteunde afstand voor synchrone replicatie is 40 kilometer, de vertragingswaarde van het optische kanaal tussen datacenters is maximaal 2 milliseconden. Over het algemeen zal het met grote vertragingen werken, maar dan zullen er sterke vertragingen optreden tijdens de opname (wat ook logisch is), dus als u synchrone replicatie tussen datacenters plant, moet u de kwaliteit van de optica en de vertragingen controleren.
De vereisten voor asynchrone replicatie zijn niet zo ernstig. Om precies te zijn: ze zijn er helemaal niet. Elke werkende Ethernet-verbinding is voldoende.
Momenteel ondersteunt het AERODISK ENGINE-opslagsysteem replicatie voor blokapparaten (LUN's) via het Ethernet-protocol (via koper of optisch). Voor projecten waarbij replicatie via een SAN-fabric over Fibre Channel vereist is, voegen we momenteel een passende oplossing toe, maar deze is nog niet klaar, dus in ons geval alleen Ethernet.
Replicatie kan werken tussen alle opslagsystemen uit de ENGINE-serie (N1, N2, N4), van juniorsystemen tot oudere systemen en omgekeerd.
De functionaliteit van beide replicatiemodi is volledig identiek. Hieronder vindt u meer informatie over wat er beschikbaar is:
- Replicatie “één op één” of “één op één”, dat wil zeggen de klassieke versie met twee datacenters, de hoofd- en de back-up
- Replicatie is “één op veel” of “één op veel”, d.w.z. één LUN kan naar meerdere opslagsystemen tegelijk worden gerepliceerd
- Activeer, deactiveer en “omgekeerde” replicatie om de replicatierichting in of uit te schakelen of te wijzigen
- Replicatie is beschikbaar voor zowel RDG-pools (Raid Distributed Group) als DDP-pools (Dynamic Disk Pool). LUN's van een RDG-pool kunnen echter alleen naar een andere RDG worden gerepliceerd. Hetzelfde met DDP.
Er zijn nog veel meer kleine functies, maar het heeft geen zin om ze op te sommen; we zullen ze vermelden tijdens het instellen.
Replicatie instellen
Het installatieproces is vrij eenvoudig en bestaat uit drie fasen.
- Netwerk configuratie
- Opslag opstelling
- Regels (verbindingen) instellen en in kaart brengen
Een belangrijk punt bij het opzetten van replicatie is dat de eerste twee fasen moeten worden herhaald op het externe opslagsysteem, en de derde fase alleen op de hoofdfase.
Netwerkbronnen instellen
De eerste stap is het configureren van de netwerkpoorten waarlangs replicatieverkeer wordt verzonden. Om dit te doen, moet u de poorten inschakelen en hun IP-adressen instellen in de sectie Front-endadapters.
Hierna moeten we een pool (in ons geval RDG) en een virtueel IP-adres voor replicatie (VIP) maken. VIP is een zwevend IP-adres dat is gekoppeld aan twee ‘fysieke’ adressen van opslagcontrollers (de poorten die we zojuist hebben geconfigureerd). Dit wordt de belangrijkste replicatie-interface. U kunt ook niet met een VIP werken, maar met een VLAN, als u met getagd verkeer moet werken.
Het proces van het maken van een VIP voor een replica verschilt niet veel van het maken van een VIP voor I/O (NFS, SMB, iSCSI). In dit geval maken we een gewone VIP aan (zonder VLAN), maar zorg ervoor dat u aangeeft dat deze voor replicatie is (zonder deze aanwijzer kunnen we in de volgende stap geen VIP aan de regel toevoegen).
De VIP moet zich in hetzelfde subnet bevinden als de IP-poorten waartussen deze zweeft.
Deze instellingen herhalen we op een extern opslagsysteem, uiteraard met een ander IP-adres.
VIP's van verschillende opslagsystemen kunnen zich in verschillende subnetten bevinden, het belangrijkste is dat er routing tussen hen is. In ons geval wordt dit voorbeeld exact weergegeven (192.168.3.XX en 192.168.2.XX)
Hiermee is de voorbereiding van het netwerkgedeelte voltooid.
Opslag instellen
Het instellen van opslag voor een replica verschilt alleen van normaal doordat we de mapping uitvoeren via een speciaal menu “Replication Mapping”. Verder is alles hetzelfde als bij de normale opstelling. Nu, in volgorde.
In de eerder gemaakte pool R02 moet u een LUN maken. Laten we het maken en het LUN1 noemen.
We moeten dezelfde LUN ook creëren op een extern opslagsysteem van identieke grootte. We creëren. Laten we, om verwarring te voorkomen, de externe LUN LUN1R bellen
Als we een LUN zouden moeten nemen die al bestaat, dan zouden we tijdens het opzetten van de replica deze productieve LUN van de host moeten ontkoppelen en eenvoudigweg een lege LUN van identieke grootte op het externe opslagsysteem moeten creëren.
De opslagconfiguratie is voltooid. Laten we verder gaan met het maken van een replicatieregel.
Replicatieregels of replicatiekoppelingen instellen
Nadat we LUN's op het opslagsysteem hebben gemaakt, wat op dit moment de primaire zal zijn, configureren we de replicatieregel LUN1 op opslagsysteem 1 tot LUN1R op opslagsysteem 2.
De instelling vindt plaats in het menu “Remote replication”.
Laten we een regel maken. Om dit te doen, moet u de ontvanger van de replica opgeven. Daar stellen we ook de naam van de verbinding en het type replicatie (synchroon of asynchroon) in.
In het veld “systemen op afstand” voegen we ons opslagsysteem2 toe. Om toe te voegen, moet u de beheer-IP-opslagsystemen (MGR) gebruiken en de naam van de externe LUN waarnaar we replicatie zullen uitvoeren (in ons geval LUN1R). Controle-IP's zijn alleen nodig in de fase van het toevoegen van een verbinding; replicatieverkeer wordt er niet doorheen verzonden; hiervoor wordt de eerder geconfigureerde VIP gebruikt.
Al in dit stadium kunnen we meer dan één systeem op afstand toevoegen voor de ‘één-op-veel’-topologie: klik op de knop ‘knooppunt toevoegen’, zoals in de onderstaande afbeelding.
In ons geval is er maar één systeem op afstand, dus beperken we ons daartoe.
De regel is klaar. Houd er rekening mee dat het automatisch wordt toegevoegd aan alle replicatiedeelnemers (in ons geval zijn dat er twee). U kunt zoveel van dergelijke regels maken als u wilt, voor een willekeurig aantal LUN's en in elke richting. Om de belasting in evenwicht te brengen, kunnen we bijvoorbeeld een deel van de LUN's repliceren van opslagsysteem 1 naar opslagsysteem 2, en het andere deel juist van opslagsysteem 2 naar opslagsysteem 1.
Opslagsysteem1. Onmiddellijk na de creatie begon de synchronisatie.
Opslagsysteem2. We zien dezelfde regel, maar de synchronisatie is al beëindigd.
LUN1 op opslagsysteem 1 heeft de primaire rol, dat wil zeggen dat het actief is. LUN1R op opslagsysteem 2 heeft de rol van secundair, dat wil zeggen dat het stand-by staat voor het geval opslagsysteem 1 uitvalt.
Nu kunnen we onze LUN verbinden met de host.
We maken verbinding via iSCSI, maar het kan ook via FC. Het opzetten van mapping via iSCSI LUN in een replica verschilt praktisch niet van het gebruikelijke scenario, dus we zullen hier hier niet in detail op ingaan. Dit proces wordt in ieder geval beschreven in het artikel “.
Het enige verschil is dat we mapping maken in het menu “Replication Mapping”.
We hebben de mapping opgezet en de LUN aan de host gegeven. De gastheer zag de LUN.
We formatteren het in een lokaal bestandssysteem.
Dat is alles, de installatie is voltooid. Tests zullen hierna volgen.
Testen
We zullen drie hoofdscenario’s testen.
- Regelmatig wisselen van rol Secundair > Primair. Regelmatig wisselen van rollen is nodig als we bijvoorbeeld een aantal preventieve handelingen moeten uitvoeren in het hoofddatacenter. Gedurende deze tijd, om ervoor te zorgen dat de gegevens beschikbaar zijn, dragen we de belasting over naar het back-updatacenter.
- Noodrolwisseling Secundair > Primair (datacenterfout). Dit is het belangrijkste scenario waarvoor replicatie bestaat, wat kan helpen een volledige datacenterstoring te overleven zonder het bedrijf voor langere tijd stil te leggen.
- Uitsplitsing van communicatiekanalen tussen datacenters. Het controleren van het juiste gedrag van twee opslagsystemen in omstandigheden waarin het communicatiekanaal tussen de datacenters om de een of andere reden niet beschikbaar is (een graafmachine heeft bijvoorbeeld op de verkeerde plaats gegraven en de donkere optiek kapot gemaakt).
Eerst zullen we beginnen met het schrijven van gegevens naar onze LUN (bestanden schrijven met willekeurige gegevens). We zien meteen dat het communicatiekanaal tussen de opslagsystemen benut wordt. Dit is gemakkelijk te begrijpen als u de belastingmonitoring opent van de poorten die verantwoordelijk zijn voor replicatie.
Beide opslagsystemen beschikken nu over “nuttige” data, we kunnen beginnen met de test.
Laten we voor de zekerheid eens kijken naar de hash-sommen van een van de bestanden en deze opschrijven.
Regelmatig wisselen van rol
Het wisselen van rol (het veranderen van de replicatierichting) kan met elk opslagsysteem worden uitgevoerd, maar u zult nog steeds naar beide moeten gaan, omdat u de toewijzing op Primair moet uitschakelen en deze op Secundair moet inschakelen (wat Primair wordt). ).
Misschien rijst er nu een redelijke vraag: waarom automatiseren we dit niet? Het antwoord is: het is simpel: replicatie is een eenvoudige manier om rampenbestendig te worden, uitsluitend gebaseerd op handmatige handelingen. Om deze bewerkingen te automatiseren is er een metroclustermodus; deze is volledig geautomatiseerd, maar de configuratie ervan is veel gecompliceerder. Over het opzetten van een metrocluster schrijven we in het volgende artikel.
Op het hoofdopslagsysteem schakelen we mapping uit om ervoor te zorgen dat de opname stopt.
Selecteer vervolgens op een van de opslagsystemen (het maakt niet uit, op de hoofd- of back-up) in het menu "Remote replicatie" onze verbinding REPL1 en klik op "Rol wijzigen".
Na een paar seconden wordt LUN1R (back-upopslagsysteem) primair.
We brengen LUN1R in kaart met opslagsysteem2.
Hierna wordt onze E: schijf automatisch aan de host gekoppeld, maar deze keer is hij “aangekomen” van LUN1R.
Voor het geval dat vergelijken we de hash-sommen.
Identiek. Test geslaagd.
Failover. Storing in het datacenter
Op dit moment is het hoofdopslagsysteem na reguliere schakeling respectievelijk opslagsysteem 2 en LUN1R. Om een ongeluk te emuleren, schakelen we beide opslagcontrollers uit2.
Er is geen toegang meer toe.
Laten we eens kijken wat er gebeurt op opslagsysteem 1 (momenteel het back-upsysteem).
We zien dat de primaire LUN (LUN1R) niet beschikbaar is. Er verscheen een foutmelding in de logbestanden, in het informatiepaneel en ook in de replicatieregel zelf. Dienovereenkomstig zijn gegevens van de host momenteel niet beschikbaar.
Wijzig de rol van LUN1 in Primair.
Ik ben bezig met mapping naar de host.
Zorg ervoor dat station E op de host verschijnt.
We controleren de hasj.
Alles is in orde. Het opslagsysteem overleefde met succes de val van het datacenter, dat actief was. De geschatte tijd die we besteedden aan het verbinden van de replicatie-‘omkering’ en het verbinden van de LUN vanuit het back-updatacenter was ongeveer 3 minuten. Het is duidelijk dat in de echte productie alles veel ingewikkelder is, en dat je naast acties met opslagsystemen nog veel meer bewerkingen moet uitvoeren op het netwerk, op hosts, in applicaties. En in het leven zal deze periode veel langer zijn.
Hier zou ik willen schrijven dat alles, de test met succes is afgerond, maar laten we ons niet haasten. Het hoofdopslagsysteem “ligt”, we weten dat toen het “viel”, het in de primaire rol zat. Wat gebeurt er als het plotseling wordt ingeschakeld? Er zullen twee primaire rollen zijn, wat gelijk staat aan datacorruptie? Laten we het nu controleren.
Laten we plotseling het onderliggende opslagsysteem inschakelen.
Het laadt een paar minuten en keert dan na een korte synchronisatie terug naar gebruik, maar in de rol van Secundair.
Alles goed. Een gespleten brein is niet gebeurd. We hebben hierover nagedacht, en na een val stijgt het opslagsysteem altijd naar de rol van Secundair, ongeacht welke rol het ‘tijdens het leven’ vervulde. Nu kunnen we met zekerheid zeggen dat de uitvaltest van het datacenter succesvol was.
Falen van communicatiekanalen tussen datacenters
De belangrijkste taak van deze test is ervoor te zorgen dat het opslagsysteem niet raar gaat doen als het tijdelijk de communicatiekanalen tussen twee opslagsystemen verliest en vervolgens weer verschijnt.
Dus. We ontkoppelen de draden tussen de opslagsystemen (laten we ons voorstellen dat ze door een graafmachine zijn gegraven).
Op Primary zien we dat er geen verband is met Secondary.
Op Secondary zien we dat er geen verbinding is met Primary.
Alles werkt prima, en we blijven gegevens naar het hoofdopslagsysteem schrijven, dat wil zeggen dat ze gegarandeerd anders zijn dan het back-upsysteem, dat wil zeggen dat ze "gescheiden" zijn.
In een paar minuten ‘repareren’ we het communicatiekanaal. Zodra de opslagsystemen elkaar zien, wordt de datasynchronisatie automatisch geactiveerd. Hier is niets van de beheerder vereist.
Na enige tijd is de synchronisatie voltooid.
De verbinding werd hersteld, het wegvallen van communicatiekanalen veroorzaakte geen noodsituaties en na het inschakelen vond de synchronisatie automatisch plaats.
Bevindingen
We hebben de theorie geanalyseerd: wat is er nodig en waarom, waar zijn de voordelen en waar zijn de nadelen. Vervolgens zetten we synchrone replicatie op tussen twee opslagsystemen.
Vervolgens werden basistests uitgevoerd voor normaal schakelen, datacenterstoringen en communicatiekanaalstoringen. In alle gevallen werkte het opslagsysteem goed. Er is geen gegevensverlies en administratieve handelingen worden tot een minimum beperkt voor een handmatig scenario.
De volgende keer zullen we de situatie ingewikkelder maken en laten zien hoe al deze logica werkt in een geautomatiseerde metrocluster in actief-actief-modus, dat wil zeggen wanneer beide opslagsystemen primair zijn en het gedrag in geval van storingen in het opslagsysteem volledig geautomatiseerd is.
Schrijf alstublieft opmerkingen, wij ontvangen graag gedegen kritiek en praktisch advies.
Tot ziens.
Bron: www.habr.com