AERODISK Engine: Disaster recovery. Del 1

Hej Habr læsere! Emnet for denne artikel vil være implementeringen af ​​disaster recovery-værktøjer i AERODISK Engine-lagersystemer. I første omgang ville vi skrive i én artikel om begge værktøjer: replikering og metrocluster, men desværre viste artiklen sig at være for lang, så vi delte artiklen op i to dele. Lad os gå fra simpelt til komplekst. I denne artikel vil vi opsætte og teste synkron replikering – vi vil droppe ét datacenter, og også bryde kommunikationskanalen mellem datacentrene og se hvad der sker.

Vores kunder stiller os ofte forskellige spørgsmål om replikering, så inden vi går videre til opsætning og test af implementeringen af ​​replikaer, vil vi fortælle dig lidt om, hvad replikering i storage er.

Lidt teori

Replikering i lagersystemer er en kontinuerlig proces med at sikre dataidentitet på flere lagersystemer samtidigt. Teknisk set udføres replikering på to måder.

Synkron replikation – dette er kopiering af data fra hovedlagersystemet til backupsystemet, efterfulgt af obligatorisk bekræftelse fra begge lagersystemer på, at dataene er blevet registreret og bekræftet. Det er efter bekræftelse på begge sider (begge lagringssystemer), at dataene anses for registrerede og kan arbejdes med. Dette sikrer garanteret dataidentitet på alle lagersystemer, der deltager i replikaen.

Fordelene ved denne metode:

• Data er altid identiske på alle lagersystemer

Ulemper:

• Høje omkostninger ved løsningen (hurtige kommunikationskanaler, dyr optisk fiber, langbølgetransceivere osv.)
• Afstandsbegrænsninger (inden for flere titusinder af kilometer)
• Der er ingen beskyttelse mod logisk datakorruption (hvis data er beskadiget (med vilje eller ved et uheld) på hovedlagersystemet, vil det automatisk og øjeblikkeligt blive ødelagt på backup-en, da dataene altid er identiske (det er paradokset)

Asynkron replikation – dette er også kopiering af data fra hovedlagersystemet til backupsystemet, men med en vis forsinkelse og uden behov for at bekræfte skrivningen på den anden side. Du kan arbejde med data umiddelbart efter at have optaget dem til hovedlagersystemet, og på backuplagersystemet vil dataene være tilgængelige efter nogen tid. Identiteten af ​​dataene i dette tilfælde er naturligvis slet ikke sikret. Dataene på backup-lagersystemet er altid lidt "fortiden".

Fordele ved asynkron replikering:

• Lavprisløsning (alle kommunikationskanaler, optik valgfri)
• Ingen afstandsbegrænsninger
• På backup-lagersystemet forringes data ikke, hvis det er beskadiget på det primære (i det mindste i nogen tid); hvis dataene bliver beskadiget, kan du altid stoppe replikaen for at forhindre datakorruption på backup-lagersystemet

Ulemper:

• Data i forskellige datacentre er altid ikke identiske

Valget af replikeringstilstand afhænger således af forretningsmålene. Hvis det er kritisk for dig, at backup-datacentret indeholder nøjagtig de samme data som hoveddatacentret (dvs. forretningskrav til RPO = 0), så bliver du nødt til at punge ud med kontanterne og affinde dig med begrænsningerne for en synkron replika. Og hvis forsinkelsen i datatilstanden er acceptabel, eller der simpelthen ikke er nogen penge, skal du helt sikkert bruge den asynkrone metode.

Lad os også separat fremhæve en sådan tilstand (mere præcist, en topologi) som en metroklynge. I metrocluster-tilstand bruges synkron replikering, men i modsætning til en almindelig replika tillader en metrocluster begge lagersystemer at fungere i aktiv tilstand. De der. du har ikke en adskillelse mellem aktive og standby datacentre. Applikationer arbejder samtidigt med to lagersystemer, som fysisk er placeret i forskellige datacentre. Nedetider under ulykker i en sådan topologi er meget små (RTO, normalt minutter). I denne artikel vil vi ikke overveje vores implementering af metroklyngen, da dette er et meget stort og rummeligt emne, så vi vil afsætte en separat næste artikel til det i forlængelse af denne.

Også meget ofte, når vi taler om replikering ved hjælp af lagersystemer, har mange mennesker et rimeligt spørgsmål: > "Mange applikationer har deres egne replikeringsværktøjer, hvorfor bruge replikering på lagersystemer? Er det bedre eller værre?

Der er ikke noget klart svar her, så her er argumenterne FOR og CONS:

Argumenter FOR lagerreplikering:

• Løsningens enkelhed. Med ét værktøj kan du replikere hele dit datasæt, uanset belastningstype og applikation. Hvis du bruger en replika fra applikationer, skal du konfigurere hver applikation separat. Hvis der er mere end 2 af dem, så er dette ekstremt arbejdskrævende og dyrt (applikationsreplikering kræver normalt en separat og ikke gratis licens for hver applikation. Men mere om det nedenfor).
• Du kan replikere hvad som helst - enhver applikation, alle data - og det vil altid være konsistent. Mange (de fleste) applikationer har ikke replikeringsmuligheder, og replikaer fra lagersystemet er den eneste måde at yde beskyttelse mod katastrofer på.
• Der er ingen grund til at betale for meget for applikationsreplikeringsfunktionalitet. Som regel er det ikke billigt, ligesom licenser til en replika af et lagersystem. Men du skal betale for en licens til lagerreplikering én gang, og en licens til programreplika skal købes for hver applikation separat. Hvis der er mange af sådanne applikationer, så koster det en pæn krone, og omkostningerne til licenser til lagerreplikering bliver en dråbe i bøtten.

Argumenter MOD lagerreplikering:

• Replika gennem applikationer har mere funktionalitet fra applikationernes synspunkt, applikationen kender sine data bedre (naturligvis), så der er flere muligheder for at arbejde med dem.
• Producenter af nogle applikationer garanterer ikke konsistensen af ​​deres data, hvis replikering udføres ved hjælp af tredjepartsværktøjer. *

* - kontroversiel afhandling. For eksempel har en velkendt DBMS-producent officielt erklæret i meget lang tid, at deres DBMS kun kan replikeres normalt ved hjælp af deres midler, og resten af ​​replikationen (inklusive lagersystemer) er "ikke sand." Men livet har vist, at det ikke er sådan. Mest sandsynligt (men det er ikke sikkert) er dette simpelthen ikke det mest ærlige forsøg på at sælge flere licenser til kunder.

Som et resultat er replikering fra lagersystemet i de fleste tilfælde bedre, fordi Dette er en enklere og billigere mulighed, men der er komplekse tilfælde, hvor der er behov for specifik applikationsfunktionalitet, og det er nødvendigt at arbejde med replikering på applikationsniveau.

Færdig med teori, øv nu

Vi konfigurerer replikaen i vores laboratorium. Under laboratorieforhold emulerede vi to datacentre (faktisk to tilstødende stativer, der så ud til at være i forskellige bygninger). Standen består af to Engine N2 opbevaringssystemer, som er forbundet med hinanden med optiske kabler. En fysisk server, der kører Windows Server 2016, er forbundet til begge lagersystemer ved hjælp af 10 Gb Ethernet. Stativet er ret simpelt, men det ændrer ikke på essensen.

Skematisk ser det sådan ud:

Logisk er replikering organiseret som følger:

Lad os nu se på replikeringsfunktionaliteten, som vi har nu.
To tilstande understøttes: asynkron og synkron. Det er logisk, at den synkrone tilstand er begrænset af afstand og kommunikationskanal. Især synkron tilstand kræver brug af fiber som fysik og 10 Gigabit Ethernet (eller højere).

Den understøttede afstand til synkron replikering er 40 kilometer, forsinkelsesværdien af ​​den optiske kanal mellem datacentre er op til 2 millisekunder. Generelt vil det fungere med store forsinkelser, men så vil der være kraftige opbremsninger under optagelsen (hvilket også er logisk), så hvis du planlægger synkron replikering mellem datacentre, bør du tjekke kvaliteten af ​​optikken og forsinkelserne.

Kravene til asynkron replikation er ikke så alvorlige. Mere præcist er de der slet ikke. Enhver fungerende Ethernet-forbindelse duer.

I øjeblikket understøtter AERODISK ENGINE-lagersystemet replikering for blokenheder (LUN'er) via Ethernet-protokollen (over kobber eller optisk). Til projekter, hvor replikering gennem et SAN-stof over Fibre Channel er påkrævet, tilføjer vi i øjeblikket en passende løsning, men den er ikke klar endnu, så i vores tilfælde kun Ethernet.

Replikering kan fungere mellem alle lagersystemer i ENGINE-serien (N1, N2, N4) fra juniorsystemer til ældre og omvendt.

Funktionaliteten af ​​begge replikeringstilstande er fuldstændig identisk. Nedenfor er flere detaljer om, hvad der er tilgængeligt:

• Replikering "en til en" eller "en til en", det vil sige den klassiske version med to datacentre, hoved og backup
• Replikation er "en til mange" eller "en til mange", dvs. en LUN kan replikeres til flere lagersystemer på én gang
• Aktiver, deaktiver og "omvendt" replikering for at aktivere, deaktivere eller ændre replikeringsretningen
• Replikering er tilgængelig for både RDG (Raid Distributed Group) og DDP (Dynamic Disk Pool) pools. LUN'er for en RDG-pulje kan dog kun replikeres til en anden RDG. Det samme med DDP.

Der er mange flere små funktioner, men der er ingen særlig mening i at liste dem; vi vil nævne dem, når vi sætter op.

Opsætning af replikering

Opsætningsprocessen er ret enkel og består af tre trin.

1. Netværkskonfiguration
2. Opsætning af opbevaring
3. Opsætning af regler (forbindelser) og kortlægning

Et vigtigt punkt ved opsætning af replikering er, at de to første trin skal gentages på fjernlagringssystemet, det tredje trin - kun på det primære.

Opsætning af netværksressourcer

Det første trin er at konfigurere netværksportene, hvorigennem replikeringstrafik vil blive transmitteret. For at gøre dette skal du aktivere portene og indstille deres IP-adresser i afsnittet Front-end-adaptere.

Herefter skal vi oprette en pulje (i vores tilfælde RDG) og en virtuel IP til replikering (VIP). VIP er en flydende IP-adresse, der er knyttet til to "fysiske" adresser på lagercontrollere (de porte, som vi lige har konfigureret). Dette vil være hovedreplikeringsgrænsefladen. Du kan også operere ikke med en VIP, men med et VLAN, hvis du skal arbejde med tagget trafik.

Processen med at oprette en VIP til en replika er ikke meget forskellig fra at oprette en VIP til I/O (NFS, SMB, iSCSI). I dette tilfælde opretter vi en almindelig VIP (uden VLAN), men sørg for at angive, at den er til replikering (uden denne pointer vil vi ikke være i stand til at tilføje VIP til reglen i næste trin).

VIP'en skal være i samme undernet som de IP-porte, som den flyder imellem.

Vi gentager disse indstillinger på et fjernlagersystem, selvfølgelig med en anden IP.
VIP'er fra forskellige lagersystemer kan være i forskellige undernet, det vigtigste er, at der er routing mellem dem. I vores tilfælde er dette eksempel nøjagtigt vist (192.168.3.XX og 192.168.2.XX)

Dette afslutter forberedelsen af ​​netværksdelen.

Opsætning af lager

Opsætning af lagring til en replika adskiller sig kun fra det sædvanlige ved, at vi laver kortlægningen gennem en speciel menu "Replication Mapping". Ellers er alt det samme som med den normale opsætning. Nu i rækkefølge.

I den tidligere oprettede pulje R02 skal du oprette en LUN. Lad os skabe det og kalde det LUN1.

Vi er også nødt til at oprette den samme LUN på et fjernlagersystem af identisk størrelse. Vi skaber. For at undgå forvirring, lad os kalde fjernbetjeningen LUN LUN1R

Hvis vi skulle tage et LUN, der allerede eksisterer, så skal vi, mens vi opsætter replikaen, afmontere dette produktive LUN fra værten og simpelthen oprette et tomt LUN af identisk størrelse på fjernlagersystemet.

Lageropsætningen er fuldført, lad os gå videre til at oprette en replikeringsregel.

Opsætning af replikeringsregler eller replikeringslinks

Efter at have oprettet LUN'er på lagersystemet, som vil være det primære i øjeblikket, konfigurerer vi replikeringsreglen LUN1 på lagersystem 1 til LUN1R på lagersystem 2.

Indstillingen foretages i menuen "Fjernreplikering".

Lad os skabe en regel. For at gøre dette skal du angive modtageren af ​​replikaen. Der sætter vi også navnet på forbindelsen og typen af ​​replikering (synkron eller asynkron).

I feltet "fjernsystemer" tilføjer vi vores lagersystem2. For at tilføje skal du bruge administrations-IP-lagringssystemerne (MGR) og navnet på den eksterne LUN, som vi vil udføre replikering i (i vores tilfælde LUN1R). Kontrol-IP'er er kun nødvendige på tidspunktet for tilføjelse af en forbindelse; replikeringstrafik vil ikke blive transmitteret gennem dem; den tidligere konfigurerede VIP vil blive brugt til dette.

Allerede på dette stadium kan vi tilføje mere end ét fjernsystem til "en til mange"-topologien: klik på knappen "tilføj node", som i figuren nedenfor.

I vores tilfælde er der kun ét fjernsystem, så vi begrænser os til dette.

Reglen er klar. Bemærk venligst, at det tilføjes automatisk på alle replikeringsdeltagere (i vores tilfælde er der to af dem). Du kan oprette så mange sådanne regler, som du vil, for et hvilket som helst antal LUN'er og i enhver retning. For at afbalancere belastningen kan vi for eksempel replikere en del af LUN'erne fra lagersystem 1 til lagersystem 2, og den anden del tværtimod fra lagersystem 2 til lagersystem 1.

Opbevaringssystem 1. Umiddelbart efter oprettelsen begyndte synkroniseringen.

Opbevaringssystem 2. Vi ser den samme regel, men synkroniseringen er allerede afsluttet.

LUN1 på lagersystem 1 er i den primære rolle, det vil sige, den er aktiv. LUN1R på lagersystem 2 er i rollen som sekundær, det vil sige, at den er på standby, hvis lagersystem 1 fejler.
Nu kan vi forbinde vores LUN til værten.

Vi vil forbinde via iSCSI, selvom det også kan gøres via FC. Opsætning af kortlægning via iSCSI LUN i en replika er praktisk talt ikke forskellig fra det sædvanlige scenarie, så vi vil ikke overveje dette i detaljer her. Hvis noget, er denne proces beskrevet i artiklen "Hurtig opsætning'.

Den eneste forskel er, at vi opretter kortlægning i menuen "Replication Mapping".

Vi satte kortlægning op og gav LUN til værten. Værten så LUN.

Vi formaterer det til et lokalt filsystem.

Det er det, opsætningen er færdig. Prøverne kommer næste gang.

Test

Vi vil teste tre hovedscenarier.

1. Regelmæssig rolleskift Sekundær > Primær. Regelmæssigt rolleskift er nødvendigt i tilfælde af, at vi for eksempel skal udføre nogle forebyggende operationer i hoveddatacentret, og i løbet af denne tid overfører vi belastningen til backupdatacentret, for at dataene er tilgængelige.
2. Emergency rolle switching Sekundær > Primær (datacenterfejl). Dette er hovedscenariet, som replikering eksisterer for, som kan hjælpe med at overleve et komplet datacenterfejl uden at stoppe virksomheden i en længere periode.
3. Nedbrydning af kommunikationskanaler mellem datacentre. Kontrol af den korrekte opførsel af to lagersystemer under forhold, hvor kommunikationskanalen mellem datacentrene af en eller anden grund er utilgængelig (f.eks. gravede en gravemaskine det forkerte sted og knækkede den mørke optik).

Først vil vi begynde at skrive data til vores LUN (skrive filer med tilfældige data). Vi ser med det samme, at kommunikationskanalen mellem lagersystemerne bliver udnyttet. Dette er let at forstå, hvis du åbner belastningsovervågningen af ​​de porte, der er ansvarlige for replikering.

Begge lagersystemer har nu "nyttige" data, vi kan starte testen.

For en sikkerheds skyld, lad os se på hash-summen for en af ​​filerne og skrive dem ned.

Regelmæssigt rolleskift

Funktionen af ​​at skifte roller (ændring af replikeringsretningen) kan udføres med ethvert lagersystem, men du skal stadig gå til begge dele, da du bliver nødt til at deaktivere kortlægning på Primary og aktivere den på Secondary (som bliver Primary) ).

Måske opstår et rimeligt spørgsmål nu: hvorfor ikke automatisere dette? Svaret er: det er enkelt, replikering er et simpelt middel til katastrofemodstandsdygtighed, udelukkende baseret på manuelle operationer. For at automatisere disse operationer er der en metrocluster-tilstand; den er fuldt automatiseret, men dens konfiguration er meget mere kompliceret. Vi vil skrive om oprettelse af en metroklynge i næste artikel.

På hovedlagersystemet deaktiverer vi kortlægning for at sikre, at optagelsen stopper.

Vælg derefter vores forbindelse REPL1 på et af lagersystemerne (det er lige meget, på hoved- eller backup) i menuen "Fjernreplikering" og klik på "Skift rolle".

Efter et par sekunder bliver LUN1R (backup storage system) Primær.

Vi kortlægger LUN1R med lagersystem2.

Herefter er vores E:-drev automatisk knyttet til værten, kun denne gang "ankom" det fra LUN1R.

For en sikkerheds skyld sammenligner vi hash-beløbene.

Identisk. Test bestået.

Failover. Datacenterfejl

I øjeblikket er hovedlagersystemet efter almindelig skift henholdsvis lagersystem 2 og LUN1R. For at efterligne en ulykke slukker vi for strømmen på begge lagercontrollere2.
Der er ikke længere adgang til det.

Lad os se, hvad der sker på lagersystem 1 (det sikkerhedskopierede i øjeblikket).

Vi ser, at den primære LUN (LUN1R) ikke er tilgængelig. En fejlmeddelelse dukkede op i logfilerne, i informationspanelet og også i selve replikeringsreglen. Derfor er data fra værten i øjeblikket ikke tilgængelige.

Skift rollen som LUN1 til Primær.

Jeg laver kortlægning til værten.

Sørg for, at drev E vises på værten.

Vi tjekker hashen.

Alt er fint. Lagersystemet overlevede med succes datacentrets fald, som var aktivt. Den omtrentlige tid, vi brugte på at forbinde replikeringen "tilbageførsel" og forbinde LUN'et fra backupdatacentret, var omkring 3 minutter. Det er klart, at i virkelig produktion er alt meget mere kompliceret, og ud over handlinger med lagersystemer skal du udføre mange flere operationer på netværket, på værter, i applikationer. Og i livet vil denne periode være meget længere.

Her vil jeg gerne skrive, at alt, testen er blevet gennemført med succes, men lad os ikke skynde os. Hovedlagersystemet "lyver", vi ved, at da det "faldt", var det i den primære rolle. Hvad sker der, hvis den pludselig tænder? Der vil være to primære roller, hvilket er lig med datakorruption? Lad os tjekke det nu.
Lad os pludselig tænde for det underliggende lagersystem.

Den indlæses i et par minutter og vender derefter tilbage til tjeneste efter en kort synkronisering, men i rollen som sekundær.

Alt er OK. Split-brain skete ikke. Vi tænkte på dette, og altid efter et fald stiger lagersystemet til rollen som sekundært, uanset hvilken rolle det var i "i livet." Nu kan vi med sikkerhed sige, at testen af ​​datacenterfejl var vellykket.

Fejl i kommunikationskanaler mellem datacentre

Hovedopgaven med denne test er at sikre, at lagringssystemet ikke begynder at opføre sig underligt, hvis det midlertidigt mister kommunikationskanaler mellem to lagringssystemer og derefter dukker op igen.
Så. Vi afbryder ledningerne mellem opbevaringssystemerne (lad os forestille os, at de blev gravet af en gravemaskine).

På Primary ser vi, at der ikke er nogen forbindelse med Secondary.

På Secondary ser vi, at der ikke er nogen forbindelse med Primary.

Alt fungerer fint, og vi fortsætter med at skrive data til hovedlagersystemet, det vil sige, at de med garanti er forskellige fra backup-systemet, det vil sige, at de er "separeret".

På få minutter "reparerer" vi kommunikationskanalen. Så snart lagringssystemerne ser hinanden, aktiveres datasynkroniseringen automatisk. Der kræves ikke noget fra administratoren her.

Efter nogen tid er synkroniseringen fuldført.

Forbindelsen blev genoprettet, tabet af kommunikationskanaler forårsagede ingen nødsituationer, og efter tænding skete synkronisering automatisk.

Fund

Vi analyserede teorien - hvad er nødvendigt og hvorfor, hvor er fordelene og hvor er ulemperne. Derefter opsætter vi synkron replikering mellem to lagersystemer.

Derefter blev der udført grundlæggende tests for normal skift, datacenterfejl og kommunikationskanalfejl. I alle tilfælde fungerede opbevaringssystemet godt. Der er intet datatab, og administrative operationer holdes på et minimum for et manuelt scenarie.

Næste gang vil vi komplicere situationen og vise, hvordan al denne logik fungerer i en automatiseret metroklynge i aktiv-aktiv tilstand, det vil sige, når begge lagersystemer er primære, og adfærden i tilfælde af fejl i lagersystemet er fuldt automatiseret.

Skriv venligst kommentarer, vi vil med glæde modtage god kritik og praktiske råd.

Indtil næste gang.

Kilde: www.habr.com