Hei, Habr-lesere! Temaet for denne artikkelen vil være implementering av katastrofegjenopprettingsverktøy i AERODISK Engine-lagringssystemer. I utgangspunktet ønsket vi å skrive i en artikkel om begge verktøyene: replikering og metrocluster, men dessverre viste artikkelen seg å være for lang, så vi delte artikkelen i to deler. La oss gå fra enkelt til komplekst. I denne artikkelen skal vi sette opp og teste synkron replikering – vi skal droppe ett datasenter, og også bryte kommunikasjonskanalen mellom datasentrene og se hva som skjer.
Våre kunder stiller oss ofte ulike spørsmål om replikering, så før vi går videre til å sette opp og teste implementeringen av replikaer, vil vi fortelle litt om hva replikering i lagring er.
Litt teori
Replikering i lagringssystemer er en kontinuerlig prosess for å sikre dataidentitet på flere lagringssystemer samtidig. Teknisk sett utføres replikering på to måter.
Synkron replikering – dette er kopiering av data fra hovedlagringssystemet til backupsystemet, etterfulgt av obligatorisk bekreftelse fra begge lagringssystemene om at dataene er registrert og bekreftet. Det er etter bekreftelse på begge sider (begge lagringssystemene) at dataene anses som registrert og kan arbeides med. Dette sikrer garantert dataidentitet på alle lagringssystemer som deltar i replikaen.
Fordelene med denne metoden:
- Data er alltid identiske på alle lagringssystemer
Cons:
- Høye kostnader for løsningen (raske kommunikasjonskanaler, dyr optisk fiber, langbølgesendere, etc.)
- Avstandsbegrensninger (innen flere titalls kilometer)
- Det er ingen beskyttelse mot logisk datakorrupsjon (hvis data er ødelagt (med vilje eller ved et uhell) på hovedlagringssystemet, vil det automatisk og øyeblikkelig bli ødelagt på backupen, siden dataene alltid er identiske (det er paradokset)
Asynkron replikering – dette er også kopiering av data fra hovedlagringssystemet til backupsystemet, men med en viss forsinkelse og uten behov for å bekrefte skrivingen på den andre siden. Du kan arbeide med data umiddelbart etter opptak til hovedlagringssystemet, og på backuplagringssystemet vil dataene være tilgjengelige etter en stund. Identiteten til dataene i dette tilfellet er selvfølgelig ikke sikret i det hele tatt. Dataene på backup-lagringssystemet er alltid litt "i fortiden."
Fordeler med asynkron replikering:
- Lavprisløsning (alle kommunikasjonskanaler, optikk valgfritt)
- Ingen avstandsbegrensninger
- På lagringssystemet for sikkerhetskopiering forringes ikke data hvis det er skadet på hovedsystemet (i det minste i noen tid); hvis dataene blir ødelagt, kan du alltid stoppe replikaen for å forhindre datakorrupsjon på lagringssystemet for sikkerhetskopiering
Cons:
- Data i forskjellige datasentre er alltid ikke identiske
Valget av replikeringsmodus avhenger derfor av forretningsmålene. Hvis det er kritisk for deg at backupdatasenteret inneholder nøyaktig de samme dataene som hoveddatasenteret (dvs. forretningskrav for RPO = 0), så må du punge ut pengene og tåle begrensningene til en synkron replika. Og hvis forsinkelsen i datatilstanden er akseptabel eller det rett og slett ikke er penger, må du definitivt bruke den asynkrone metoden.
La oss også særskilt fremheve en slik modus (mer presist, en topologi) som en metroklynge. I metrocluster-modus brukes synkron replikering, men i motsetning til en vanlig replika, lar en metrocluster begge lagringssystemene operere i aktiv modus. De. du har ikke et skille mellom aktive og standby-datasentre. Applikasjoner fungerer samtidig med to lagringssystemer, som er fysisk plassert i forskjellige datasentre. Nedetider under ulykker i en slik topologi er svært små (RTO, vanligvis minutter). I denne artikkelen vil vi ikke vurdere implementeringen vår av metroklyngen, siden dette er et veldig stort og romslig emne, så vi vil vie en egen, neste artikkel til den, i fortsettelsen av denne.
Også, veldig ofte, når vi snakker om replikering ved bruk av lagringssystemer, har mange mennesker et rimelig spørsmål: > "Mange applikasjoner har sine egne replikeringsverktøy, hvorfor bruke replikering på lagringssystemer? Er det bedre eller verre?
Det er ikke noe klart svar her, så her er argumentene FOR og CONS:
Argumenter FOR lagringsreplikering:
- Enkelheten av løsningen. Med ett verktøy kan du replikere hele datasettet ditt, uavhengig av belastningstype og applikasjon. Hvis du bruker en replika fra applikasjoner, må du konfigurere hver applikasjon separat. Hvis det er mer enn 2 av dem, er dette ekstremt arbeidskrevende og dyrt (applikasjonsreplikering krever vanligvis en separat og ikke gratis lisens for hver applikasjon. Men mer om det nedenfor).
- Du kan replikere hva som helst - hvilken som helst applikasjon, alle data - og det vil alltid være konsistent. Mange (de fleste) applikasjoner har ikke replikeringsmuligheter, og kopier fra lagringssystemet er den eneste måten å gi beskyttelse mot katastrofer.
- Det er ikke nødvendig å betale for mye for applikasjonsreplikeringsfunksjonalitet. Som regel er det ikke billig, akkurat som lisenser for en kopi av et lagringssystem. Men du må betale for en lisens for lagringsreplikering én gang, og en lisens for applikasjonsreplika må kjøpes for hver applikasjon separat. Hvis det er mange slike applikasjoner, så koster det en pen krone og kostnadene for lisenser for lagringsreplikering blir en dråpe i havet.
Argumenter MOT lagringsreplikering:
- Replika gjennom applikasjoner har mer funksjonalitet fra applikasjonenes synspunkt, applikasjonen kjenner dataene sine bedre (selvsagt), så det er flere muligheter for å jobbe med dem.
- Produsenter av enkelte applikasjoner garanterer ikke konsistensen til dataene deres hvis replikering utføres ved hjelp av tredjepartsverktøy. *
* - kontroversiell avhandling. For eksempel har en kjent DBMS-produsent offisielt erklært i svært lang tid at deres DBMS bare kan replikeres normalt ved bruk av deres midler, og resten av replikeringen (inkludert lagringssystemer) er "ikke sant." Men livet har vist at det ikke er slik. Mest sannsynlig (men dette er ikke sikkert) er dette rett og slett ikke det mest ærlige forsøket på å selge flere lisenser til kunder.
Som et resultat, i de fleste tilfeller, er replikering fra lagringssystemet bedre, fordi Dette er et enklere og rimeligere alternativ, men det er komplekse tilfeller der spesifikk applikasjonsfunksjonalitet er nødvendig, og det er nødvendig å jobbe med replikering på applikasjonsnivå.
Ferdig med teori, nå øv
Vi vil konfigurere replikaen i laboratoriet vårt. Under laboratorieforhold emulerte vi to datasentre (faktisk to tilstøtende stativer som så ut til å være i forskjellige bygninger). Stativet består av to Engine N2 lagringssystemer, som er koblet til hverandre med optiske kabler. En fysisk server som kjører Windows Server 2016 er koblet til begge lagringssystemene ved hjelp av 10 Gb Ethernet. Stativet er ganske enkelt, men dette endrer ikke essensen.
Skjematisk ser det slik ut:
Logisk er replikering organisert som følger:
La oss nå se på replikeringsfunksjonaliteten vi har nå.
To moduser støttes: asynkron og synkron. Det er logisk at den synkrone modusen er begrenset av avstand og kommunikasjonskanal. Spesielt synkron modus krever bruk av fiber som fysikk og 10 Gigabit Ethernet (eller høyere).
Den støttede avstanden for synkron replikering er 40 kilometer, forsinkelsesverdien til den optiske kanalen mellom datasentre er opptil 2 millisekunder. Generelt vil det fungere med store forsinkelser, men da vil det være kraftige forsinkelser under opptak (noe som også er logisk), så hvis du planlegger synkron replikering mellom datasentre bør du sjekke kvaliteten på optikken og forsinkelsene.
Kravene til asynkron replikering er ikke så alvorlige. Mer presist er de ikke der i det hele tatt. Enhver fungerende Ethernet-tilkobling vil fungere.
For øyeblikket støtter AERODISK ENGINE-lagringssystemet replikering for blokkenheter (LUN-er) via Ethernet-protokollen (over kobber eller optisk). For prosjekter der replikering gjennom et SAN-stoff over Fibre Channel er nødvendig, legger vi for tiden til en passende løsning, men den er ikke klar ennå, så i vårt tilfelle kun Ethernet.
Replikering kan fungere mellom alle lagringssystemer i ENGINE-serien (N1, N2, N4) fra juniorsystemer til eldre og omvendt.
Funksjonaliteten til begge replikeringsmodusene er helt identiske. Nedenfor finner du mer informasjon om hva som er tilgjengelig:
- Replikering "en til en" eller "en til en", det vil si den klassiske versjonen med to datasentre, hoved- og sikkerhetskopien
- Replikering er "en til mange" eller "en til mange", dvs. en LUN kan replikeres til flere lagringssystemer samtidig
- Aktiver, deaktiver og "reverser" replikering, henholdsvis for å aktivere, deaktivere eller endre retningen for replikering
- Replikering er tilgjengelig for både RDG (Raid Distributed Group) og DDP (Dynamic Disk Pool)-pooler. Imidlertid kan LUN-er for en RDG-pool bare replikeres til en annen RDG. Samme med DDP.
Det er mange flere små funksjoner, men det er ikke noe spesielt poeng å liste dem opp; vi vil nevne dem når vi setter opp.
Sette opp replikering
Oppsettprosessen er ganske enkel og består av tre trinn.
- Nettverkskonfigurasjon
- Lagringsoppsett
- Sette opp regler (tilkoblinger) og kartlegging
Et viktig poeng i å sette opp replikering er at de to første trinnene skal gjentas på fjernlagringssystemet, det tredje trinnet - bare på det viktigste.
Sette opp nettverksressurser
Det første trinnet er å konfigurere nettverksportene som replikeringstrafikk skal overføres gjennom. For å gjøre dette, må du aktivere portene og angi IP-adressene deres i delen for grensesnittadaptere.
Etter dette må vi lage en pool (i vårt tilfelle RDG) og en virtuell IP for replikering (VIP). VIP er en flytende IP-adresse som er knyttet til to "fysiske" adresser til lagringskontrollere (portene vi nettopp konfigurerte). Dette vil være hovedreplikeringsgrensesnittet. Du kan også operere ikke med en VIP, men med et VLAN, hvis du trenger å jobbe med merket trafikk.
Prosessen med å lage en VIP for en replika er ikke mye forskjellig fra å lage en VIP for I/O (NFS, SMB, iSCSI). I dette tilfellet oppretter vi en vanlig VIP (uten VLAN), men sørg for å indikere at den er for replikering (uten denne pekeren vil vi ikke kunne legge til VIP i regelen i neste trinn).
VIP-en må være i samme undernett som IP-portene den flyter mellom.
Vi gjentar disse innstillingene på et eksternt lagringssystem, med en annen IP, selvfølgelig.
VIP-er fra forskjellige lagringssystemer kan være i forskjellige undernett, det viktigste er at det er ruting mellom dem. I vårt tilfelle er dette eksemplet nøyaktig vist (192.168.3.XX og 192.168.2.XX)
Dette fullfører utarbeidelsen av nettverksdelen.
Setter opp lagring
Oppsett av lagring for en replika skiller seg fra vanlig bare ved at vi gjør kartleggingen gjennom en spesiell meny "Replication Mapping". Ellers er alt det samme som med vanlig oppsett. Nå, i rekkefølge.
I den tidligere opprettede pool R02 må du opprette en LUN. La oss lage den og kalle den LUN1.
Vi må også lage samme LUN på et eksternt lagringssystem av identisk størrelse. Vi skaper. For å unngå forvirring, la oss ringe den eksterne LUN LUN1R
Hvis vi trengte å ta et LUN som allerede eksisterer, så mens vi setter opp replikaen, må vi avmontere denne produktive LUN fra verten, og ganske enkelt opprette en tom LUN med identisk størrelse på det eksterne lagringssystemet.
Lagringsoppsettet er fullført, la oss gå videre til å lage en replikeringsregel.
Sette opp replikeringsregler eller replikeringskoblinger
Etter å ha opprettet LUN-er på lagringssystemet, som vil være det primære for øyeblikket, konfigurerer vi replikeringsregelen LUN1 på lagringssystem 1 til LUN1R på lagringssystem 2.
Innstillingen gjøres i menyen "Ekstern replikering".
La oss lage en regel. For å gjøre dette må du spesifisere mottakeren av kopien. Der setter vi også navnet på forbindelsen og typen replikering (synkron eller asynkron).
I feltet "fjernsystemer" legger vi til vårt lagringssystem2. For å legge til, må du bruke administrasjons-IP-lagringssystemene (MGR) og navnet på den eksterne LUN-en som vi skal utføre replikering i (i vårt tilfelle, LUN1R). Kontroll-IP-er er bare nødvendig på stadiet for å legge til en tilkobling; replikeringstrafikk vil ikke bli overført gjennom dem; den tidligere konfigurerte VIP-en vil bli brukt til dette.
Allerede på dette stadiet kan vi legge til mer enn ett eksternt system for "en til mange"-topologien: klikk på "legg til node"-knappen, som i figuren nedenfor.
I vårt tilfelle er det kun ett eksternt system, så vi begrenser oss til dette.
Regelen er klar. Vær oppmerksom på at det legges til automatisk på alle replikeringsdeltakere (i vårt tilfelle er det to av dem). Du kan lage så mange slike regler du vil, for et hvilket som helst antall LUN-er og i hvilken som helst retning. For eksempel, for å balansere belastningen, kan vi replikere en del av LUN-ene fra lagringssystem 1 til lagringssystem 2, og den andre delen, tvert imot, fra lagringssystem 2 til lagringssystem 1.
Oppbevaringssystem 1. Umiddelbart etter opprettelsen begynte synkroniseringen.
Lagringssystem 2. Vi ser den samme regelen, men synkroniseringen er allerede avsluttet.
LUN1 på lagringssystem 1 er i Primær-rollen, det vil si at den er aktiv. LUN1R på lagringssystem 2 er i rollen som Secondary, det vil si at den er i standby i tilfelle lagringssystem 1 svikter.
Nå kan vi koble vår LUN til verten.
Vi vil koble til via iSCSI, selv om det også kan gjøres via FC. Å sette opp kartlegging via iSCSI LUN i en replika er praktisk talt ikke forskjellig fra det vanlige scenariet, så vi vil ikke vurdere dette i detalj her. Hvis noe, er denne prosessen beskrevet i artikkelen "'.
Den eneste forskjellen er at vi lager kartlegging i menyen "Replikeringskartlegging".
Vi satte opp kartlegging og ga LUN til verten. Verten så LUN.
Vi formaterer det til et lokalt filsystem.
Det er det, oppsettet er fullført. Tester kommer neste gang.
Testing
Vi skal teste tre hovedscenarier.
- Vanlig rollebytte Sekundær > Primær. Regelmessig rollebytte er nødvendig i tilfelle vi for eksempel må utføre noen forebyggende operasjoner i hoveddatasenteret, og i løpet av denne tiden, for at dataene skal være tilgjengelige, overfører vi lasten til backupdatasenteret.
- Nødbytte av rolle Sekundær > Primær (datasenterfeil). Dette er hovedscenarioet som replikering eksisterer for, som kan bidra til å overleve en fullstendig datasentersvikt uten å stoppe selskapet i en lengre periode.
- Sammenbrudd av kommunikasjonskanaler mellom datasentre. Kontrollere riktig oppførsel av to lagringssystemer i forhold der kommunikasjonskanalen mellom datasentrene av en eller annen grunn er utilgjengelig (for eksempel grave en gravemaskin på feil sted og brøt den mørke optikken).
Først vil vi begynne å skrive data til vår LUN (skrive filer med tilfeldige data). Vi ser umiddelbart at kommunikasjonskanalen mellom lagringssystemene blir utnyttet. Dette er lett å forstå hvis du åpner lastovervåkingen av portene som er ansvarlige for replikering.
Begge lagringssystemene har nå "nyttige" data, vi kan starte testen.
Bare i tilfelle, la oss se på hash-summene til en av filene og skrive dem ned.
Regelmessig rollebytte
Operasjonen av å bytte roller (endre retningen for replikering) kan gjøres med et hvilket som helst lagringssystem, men du må fortsatt gå til begge, siden du må deaktivere kartlegging på primær, og aktivere den på sekundær (som vil bli primær ).
Kanskje dukker det opp et rimelig spørsmål nå: hvorfor ikke automatisere dette? Svaret er: det er enkelt, replikering er et enkelt middel for katastrofebestandighet, basert utelukkende på manuelle operasjoner. For å automatisere disse operasjonene er det en metrocluster-modus; den er helautomatisert, men konfigurasjonen er mye mer komplisert. Vi vil skrive om å sette opp en metroklynge i neste artikkel.
På hovedlagringssystemet deaktiverer vi kartlegging for å sikre at opptaket stopper.
Så på et av lagringssystemene (det spiller ingen rolle, på hoved- eller sikkerhetskopi) i menyen "Ekstern replikering", velg tilkoblingen REPL1 og klikk på "Endre rolle".
Etter noen sekunder blir LUN1R (backup storage system) Primær.
Vi kartlegger LUN1R med lagringssystem2.
Etter dette blir E:-stasjonen vår automatisk koblet til verten, bare denne gangen "kom" den fra LUN1R.
For sikkerhets skyld sammenligner vi hasj-summene.
Identisk. Test bestått.
Failover. Datasenterfeil
For øyeblikket er hovedlagringssystemet etter vanlig veksling henholdsvis lagringssystem 2 og LUN1R. For å etterligne en ulykke, slår vi av strømmen på begge lagringskontrollerne2.
Det er ikke lenger tilgang til det.
La oss se hva som skjer på lagringssystem 1 (det sikkerhetskopi for øyeblikket).
Vi ser at Primær LUN (LUN1R) er utilgjengelig. En feilmelding dukket opp i loggene, i informasjonspanelet og også i selve replikeringsregelen. Følgelig er data fra verten for øyeblikket utilgjengelig.
Endre rollen til LUN1 til Primær.
Jeg gjør kartlegging til verten.
Sørg for at stasjon E vises på verten.
Vi sjekker hasjen.
Alt er bra. Lagringssystemet overlevde fallet til datasenteret, som var aktivt. Den omtrentlige tiden vi brukte på å koble til replikeringen "reversering" og koble til LUN fra backupdatasenteret var omtrent 3 minutter. Det er klart at i ekte produksjon er alt mye mer komplisert, og i tillegg til handlinger med lagringssystemer, må du utføre mange flere operasjoner på nettverket, på verter, i applikasjoner. Og i livet vil denne perioden være mye lengre.
Her vil jeg skrive at alt, testen er fullført, men la oss ikke forhaste oss. Hovedlagringssystemet "lyver", vi vet at når det "falt", var det i Primær-rollen. Hva skjer hvis den plutselig slår seg på? Det vil være to primære roller, som tilsvarer datakorrupsjon? La oss sjekke det nå.
La oss plutselig slå på det underliggende lagringssystemet.
Den laster i noen minutter og går deretter tilbake til tjeneste etter en kort synkronisering, men i rollen som sekundær.
Alt ok. Split-brain skjedde ikke. Vi tenkte på dette, og alltid etter et fall stiger lagringssystemet til rollen som sekundær, uavhengig av hvilken rolle det var i "i løpet av livet." Nå kan vi med sikkerhet si at datasenterfeiltesten var vellykket.
Svikt i kommunikasjonskanaler mellom datasentre
Hovedoppgaven til denne testen er å sørge for at lagringssystemet ikke begynner å oppføre seg rart hvis det midlertidig mister kommunikasjonskanaler mellom to lagringssystemer og så dukker opp igjen.
Så. Vi kobler fra ledningene mellom lagringssystemene (la oss forestille oss at de ble gravd av en gravemaskin).
På Primær ser vi at det ikke er noen sammenheng med Secondary.
På Secondary ser vi at det ikke er noen sammenheng med Primær.
Alt fungerer bra, og vi fortsetter å skrive data til hovedlagringssystemet, det vil si at de garantert er forskjellig fra sikkerhetskopien, det vil si at de har "separert".
På noen få minutter "reparerer" vi kommunikasjonskanalen. Så snart lagringssystemene ser hverandre, aktiveres datasynkronisering automatisk. Ingenting kreves fra administratoren her.
Etter en tid er synkroniseringen fullført.
Forbindelsen ble gjenopprettet, tapet av kommunikasjonskanaler forårsaket ingen nødsituasjoner, og etter slått på skjedde synkronisering automatisk.
Funn
Vi analyserte teorien - hva er nødvendig og hvorfor, hvor er fordelene og hvor er ulempene. Deretter setter vi opp synkron replikering mellom to lagringssystemer.
Deretter ble det utført grunnleggende tester for normal veksling, datasenterfeil og kommunikasjonskanalfeil. I alle tilfeller fungerte lagringssystemet bra. Det er ingen tap av data og administrative operasjoner holdes på et minimum for et manuelt scenario.
Neste gang vil vi komplisere situasjonen og vise hvordan all denne logikken fungerer i en automatisert metroklynge i aktiv-aktiv modus, det vil si når begge lagringssystemene er primære, og atferden i tilfelle lagringssystemfeil er helautomatisert.
Skriv kommentarer, vi vil gjerne motta god kritikk og praktiske råd.
Til neste gang.
Kilde: www.habr.com