Hei, Habr-lesere! I den siste artikkelen snakket vi om en enkel måte å gjenopprette katastrofe i AERODISK ENGINE lagringssystemer - replikering. I denne artikkelen vil vi dykke inn i et mer komplekst og interessant emne - metroklyngen, det vil si et middel for automatisert katastrofebeskyttelse for to datasentre, som lar datasentre operere i aktiv-aktiv modus. Vi skal fortelle deg, vise deg, bryte den og fikse den.
Som vanlig, teori først
En metroklynge er en klynge spredt over flere steder innenfor en by eller region. Ordet "klynge" antyder tydelig for oss at komplekset er automatisert, det vil si at bytte av klynge noder i tilfelle feil skjer automatisk.
Det er her hovedforskjellen mellom en metrocluster og vanlig replikering ligger. Automatisering av operasjoner. Det vil si at i tilfelle visse hendelser (datasenterfeil, ødelagte kanaler osv.), vil lagringssystemet uavhengig utføre de nødvendige handlingene for å opprettholde datatilgjengeligheten. Når du bruker vanlige replikaer, utføres disse handlingene helt eller delvis manuelt av administratoren.
Hva gjør den?
Hovedmålet som kunder etterstreber når de bruker visse metrocluster-implementeringer, er å minimere RTO (Recovery Time Objective). Det vil si å minimere gjenopprettingstiden for IT-tjenester etter en feil. Hvis du bruker vanlig replikering, vil gjenopprettingstiden alltid være lengre enn gjenopprettingstiden med en metrocluster. Hvorfor? Veldig enkelt. Administratoren må være ved skrivebordet og bytte replikering manuelt, og metroclusteret gjør dette automatisk.
Hvis du ikke har en dedikert administrator på vakt som ikke sover, ikke spiser, ikke røyker eller blir syk og ser på tilstanden til lagringssystemet 24 timer i døgnet, så er det ingen måte å garantere at administratoren vil være tilgjengelig for manuell veksling under en feil.
Følgelig vil RTO i fravær av en metroklynge eller en udødelig administrator på 99. nivå av administratortjenesten være lik summen av byttetiden for alle systemer og den maksimale tidsperioden som administratoren garantert begynner å jobbe etter. med lagringssystemer og tilhørende systemer.
Dermed kommer vi til den åpenbare konklusjonen at metroklyngen bør benyttes dersom kravet til RTO er minutter, ikke timer eller dager.Det vil si når ved den verste datasentersvikten skal IT-avdelingen gi virksomheten tid for å gjenopprette tilgangen til IT-tjenester i løpet av minutter, eller til og med sekunder.
Hvordan virker det?
På lavere nivå bruker metrocluster en mekanisme for synkron datareplikering, som vi beskrev i forrige artikkel (se. ). Siden replikering er synkron, er kravene til den tilsvarende, eller rettere sagt:
- optisk fiber som fysikk, 10 gigabit Ethernet (eller høyere);
- avstanden mellom datasentre er ikke mer enn 40 kilometer;
- optisk kanalforsinkelse mellom datasentre (mellom lagringssystemer) er opptil 5 millisekunder (optimalt 2).
Alle disse kravene er av rådgivende karakter, det vil si at metroklyngen vil fungere selv om disse kravene ikke oppfylles, men vi må forstå at konsekvensene av manglende overholdelse av disse kravene er lik en nedgang i driften av begge lagringssystemene i metroklyngen.
Så, en synkron kopi brukes til å overføre data mellom lagringssystemer, og hvordan bytter replikaer automatisk og, viktigst av alt, hvordan unngå split-brain? For å gjøre dette, på et høyere nivå, brukes en ekstra enhet - en dommer.
Hvordan fungerer en voldgiftsdommer og hva er hans oppgave?
Arbiteren er en liten virtuell maskin eller en maskinvareklynge som må startes på en tredje side (for eksempel på et kontor) og gi tilgang til lagringssystemet via ICMP og SSH. Etter lansering skal dommeren angi IP-en, og deretter fra lagringssiden angi adressen, pluss adressene til fjernkontrollere som deltar i metroklyngen. Etter dette er dommeren klar til å jobbe.
Arbiteren overvåker hele tiden alle lagringssystemer i metroklyngen, og hvis et bestemt lagringssystem er utilgjengelig, etter å ha bekreftet utilgjengelighet fra et annet medlem av klyngen (et av de "live" lagringssystemene), bestemmer han seg for å starte prosedyren for å bytte replikeringsregler og kartlegging.
Et veldig viktig poeng. Voldgiftsdommeren må alltid være lokalisert på et annet sted enn det hvor lagringssystemene er plassert, det vil si verken i datasenter 1, hvor lagringssystem 1 er installert, eller i datasenter 2, hvor lagringssystem 2 er installert.
Hvorfor? Fordi dette er den eneste måten en voldgiftsdommer, ved hjelp av et av de overlevende lagringssystemene, entydig og nøyaktig kan fastslå fallet til noen av de to stedene der lagringssystemene er installert. Alle andre metoder for å plassere en dommer kan resultere i en splittet hjerne.
La oss nå dykke ned i detaljene i voldgiftsdommerens arbeid.
Arbiteren kjører flere tjenester som konstant poller alle lagringskontrollere. Hvis avstemningsresultatet er forskjellig fra det forrige (tilgjengelig/utilgjengelig), blir det registrert i en liten database, som også fungerer på arbiteren.
La oss se mer detaljert på logikken i voldgiftsdommerens arbeid.
Trinn 1: Bestem utilgjengelighet. En lagringssystemfeilhendelse er fraværet av ping fra begge kontrollerene i samme lagringssystem innen 5 sekunder.
Trinn 2. Start bytteprosedyren. Etter at dommeren har innsett at et av lagringssystemene er utilgjengelig, sender han en forespørsel til det "levende" lagringssystemet for å forsikre seg om at det "døde" lagringssystemet virkelig er dødt.
Etter å ha mottatt en slik kommando fra dommeren, sjekker det andre (levende) lagringssystemet i tillegg tilgjengeligheten til det falne første lagringssystemet, og hvis det ikke er der, sender det bekreftelse til dommeren om hans gjetning. Lagringssystemet er faktisk utilgjengelig.
Etter å ha mottatt en slik bekreftelse, starter dommeren en ekstern prosedyre for å bytte replikering og heve kartlegging på de replikaene som var aktive (primære) på det falne lagringssystemet, og sender en kommando til det andre lagringssystemet for å endre disse replikene fra sekundære til primære og heve kartlegging. Vel, det andre lagringssystemet utfører følgelig disse prosedyrene, og gir deretter tilgang til de tapte LUN-ene fra seg selv.
Hvorfor er det nødvendig med ytterligere bekreftelse? For quorum. Det vil si at et flertall av det totale odde (3) antallet klyngemedlemmer må bekrefte fallet til en av klyngenodene. Først da vil denne avgjørelsen være definitivt riktig. Dette er nødvendig for å unngå feilaktig veksling og følgelig splittet hjerne.
Tidstrinn 2 tar omtrent 5 - 10 sekunder, og tatt i betraktning tiden som kreves for å fastslå utilgjengelighet (5 sekunder), innen 10 - 15 sekunder etter ulykken, vil LUN-er fra det falne lagringssystemet automatisk være tilgjengelige for å arbeide med live lagringssystem.
Det er klart at for å unngå å miste forbindelsene med verter, må du også passe på å konfigurere timeouts på vertene riktig. Anbefalt tidsavbrudd er minst 30 sekunder. Dette vil forhindre at verten bryter forbindelsen til lagringssystemet under lastbytte i tilfelle en katastrofe og kan sikre at det ikke er noen I/O-avbrudd.
Vent litt, det viser seg at hvis alt er så bra med metroklyngen, hvorfor trenger vi i det hele tatt regelmessig replikering?
I virkeligheten er ikke alt så enkelt.
La oss vurdere fordelene og ulempene med metroklyngen
Så vi innså at de åpenbare fordelene med metroklyngen sammenlignet med konvensjonell replikering er:
- Full automatisering, som sikrer minimal gjenopprettingstid i tilfelle en katastrofe;
- Det er alt :-).
Og nå, oppmerksomhet, ulempene:
- Løsningskostnad. Selv om metroklyngen i Aerodisk-systemer ikke krever ytterligere lisensiering (samme lisens brukes som for replikaen), vil kostnaden for løsningen fortsatt være enda høyere enn å bruke synkron replikering. Du må implementere alle kravene til en synkron kopi, pluss kravene til metroklyngen knyttet til ekstra bytting og tilleggssted (se planlegging av metroklynge);
- Løsningens kompleksitet. Metroklyngen er mye mer kompleks enn en vanlig kopi, og krever mye mer oppmerksomhet og innsats for planlegging, konfigurasjon og dokumentasjon.
Etter hvert. Metrocluster er absolutt en svært teknologisk avansert og god løsning når du virkelig trenger å levere RTO på sekunder eller minutter. Men hvis det ikke er en slik oppgave, og RTO i timer er OK for virksomheten, så er det ingen vits i å skyte spurver fra en kanon. Den vanlige arbeider-bonde-replikeringen er tilstrekkelig, siden en metroklynge vil forårsake ekstra kostnader og komplikasjoner av IT-infrastrukturen.
Metrocluster planlegging
Denne delen hevder ikke å være en omfattende guide til design av metroklynge, men viser bare hovedretningene som bør utarbeides hvis du bestemmer deg for å bygge et slikt system. Derfor, når du faktisk implementerer en metrocluster, sørg for å involvere lagringssystemprodusenten (det vil si oss) og andre relaterte systemer for konsultasjoner.
spillesteder
Som nevnt ovenfor krever en metroklynge minimum tre steder. To datasentre hvor lagringssystemer og relaterte systemer skal operere, samt et tredje sted hvor voldgiftsdommeren skal jobbe.
Anbefalt avstand mellom datasentre er ikke mer enn 40 kilometer. En større avstand vil med stor sannsynlighet forårsake ytterligere forsinkelser, som i tilfelle av en metroklynge er ekstremt uønsket. La oss minne deg på at forsinkelser bør være opptil 5 millisekunder, selv om det er tilrådelig å holde dem innen 2.
Det anbefales å sjekke forsinkelser også under planleggingsprosessen. Enhver mer eller mindre moden leverandør som leverer optisk fiber mellom datasentre kan organisere en kvalitetssjekk ganske raskt.
Når det gjelder forsinkelser før voldgiftsdommeren (det vil si mellom det tredje nettstedet og de to første), er den anbefalte forsinkelsesterskelen opptil 200 millisekunder, det vil si at en vanlig bedrifts VPN-tilkobling over Internett er egnet.
Bytte og nettverk
I motsetning til replikeringsskjemaet, hvor det er nok å koble lagringssystemer fra forskjellige steder, krever metrocluster-ordningen å koble verter med begge lagringssystemene på forskjellige steder. For å gjøre det tydeligere hva forskjellen er, er begge ordningene vist nedenfor.
Som det kan ses av diagrammet, ser vertene våre for nettsted 1 på både lagringssystem 1 og lagringssystem 2. Tvert imot, vertene for nettsted 2 ser på både lagringssystem 2 og lagringssystem 1. Det vil si at hver vert ser begge lagringssystemene. Dette er en forutsetning for driften av metroklyngen.
Selvfølgelig er det ikke nødvendig å koble hver vert med en optisk ledning til et annet datasenter; ingen porter eller ledninger vil være nok. Alle disse tilkoblingene må gjøres gjennom Ethernet 10G+ eller FibreChannel 8G+-svitsjer (FC er kun for tilkobling av verter og lagringssystemer for IO, replikeringskanalen er foreløpig kun tilgjengelig via IP (Ethernet 10G+).
Nå noen få ord om nettverkstopologien. Et viktig poeng er riktig konfigurasjon av subnett. Det er nødvendig å umiddelbart definere flere undernett for følgende typer trafikk:
- Replikeringsundernettet som data skal synkroniseres over mellom lagringssystemer. Det kan være flere av dem, i dette tilfellet spiller det ingen rolle, alt avhenger av den nåværende (allerede implementerte) nettverkstopologien. Hvis det er to av dem, må åpenbart ruting konfigureres mellom dem;
- Lagringsundernett som verter får tilgang til lagringsressurser gjennom (hvis det er iSCSI). Det bør være ett slikt undernett i hvert datasenter;
- Kontroller undernett, det vil si tre ruterbare undernett på tre nettsteder som lagringssystemer administreres fra, og arbiteren er også lokalisert der.
Vi vurderer ikke subnett for å få tilgang til vertsressurser her, siden de er svært avhengige av oppgavene.
Å separere forskjellig trafikk i forskjellige undernett er ekstremt viktig (det er spesielt viktig å skille replikaen fra I/O-en), fordi hvis du blander all trafikken i ett "tykt" undernett, vil denne trafikken være umulig å administrere, og i forholdene til to datasentre kan dette fortsatt forårsake ulike alternativer for nettverkskollisjon. Vi vil ikke gå dypt inn i dette problemet innenfor rammen av denne artikkelen, siden du kan lese om planlegging av et nettverk strukket mellom datasentre på ressursene til produsenter av nettverksutstyr, hvor dette er beskrevet i stor detalj.
Arbiter-konfigurasjon
Dommeren må gi tilgang til alle administrasjonsgrensesnittene til lagringssystemet via ICMP- og SSH-protokollene. Du bør også tenke på feilsikkerheten til dommeren. Det er en nyanse her.
Arbiter failover er svært ønskelig, men ikke nødvendig. Hva skjer hvis dommeren krasjer på feil tidspunkt?
- Operasjonen til metroklyngen i normal modus vil ikke endres, fordi arbtir har absolutt ingen effekt på driften av metroklyngen i normal modus (oppgaven er å bytte belastningen mellom datasentre i tide)
- Dessuten, hvis dommeren av en eller annen grunn faller og "sover gjennom" en ulykke i datasenteret, vil ingen bytte skje, fordi det ikke vil være noen som gir de nødvendige byttekommandoene og organiserer et quorum. I dette tilfellet vil metroklyngen bli til en vanlig ordning med replikering, som må byttes manuelt under en katastrofe, noe som vil påvirke RTO.
Hva følger av dette? Hvis du virkelig trenger å sikre et minimum RTO, må du sørge for at dommeren er feiltolerant. Det er to alternativer for dette:
- Start en virtuell maskin med en arbiter på en feiltolerant hypervisor, heldigvis støtter alle voksne hypervisorer feiltoleranse;
- Hvis du på det tredje stedet (på et konvensjonelt kontor) er for lat til å installere en vanlig klynge og det ikke er noen eksisterende hypervozor-klynge, så har vi levert en maskinvareversjon av arbiteren, som er laget i en 2U-boks der to vanlige x-86-servere fungerer og som kan overleve en lokal feil.
Vi anbefaler på det sterkeste å sikre feiltoleransen til arbiteren, til tross for at metroclusteret ikke trenger det i normal modus. Men som både teori og praksis viser, hvis du bygger en virkelig pålitelig katastrofesikker infrastruktur, er det bedre å spille det trygt. Det er bedre å beskytte deg selv og virksomheten din mot "sanshetens lov", det vil si fra feilen til både voldgiftsdommeren og et av nettstedene der lagringssystemet er plassert.
Løsningsarkitektur
Med tanke på kravene ovenfor får vi følgende generelle løsningsarkitektur.
LUN-er bør være jevnt fordelt på to steder for å unngå alvorlig overbelastning. Samtidig bør du, når du dimensjonerer i begge datasentrene, inkludere ikke bare dobbelt volum (som er nødvendig for å lagre data samtidig på to lagringssystemer), men også dobbel ytelse i IOPS og MB/s for å forhindre applikasjonsdegradering i tilfelle av feil i et av datasentrene ov.
Separat bemerker vi at med riktig tilnærming til dimensjonering (det vil si forutsatt at vi har gitt de riktige øvre grensene for IOPS og MB/s, samt nødvendige CPU- og RAM-ressurser), hvis et av lagringssystemene i metroklynge svikter, vil det ikke være et alvorlig fall i ytelse under forhold midlertidig arbeid på ett lagringssystem.
Dette forklares av det faktum at når to nettsteder opererer samtidig, "spiser" synkron replikering halvparten av skriveytelsen, siden hver transaksjon må skrives til to lagringssystemer (i likhet med RAID-1/10). Så hvis et av lagringssystemene svikter, forsvinner påvirkningen av replikering midlertidig (til det mislykkede lagringssystemet gjenoppretter), og vi får en dobbel økning i skriveytelse. Etter at LUN-ene til det mislykkede lagringssystemet er startet på nytt på det fungerende lagringssystemet, forsvinner denne doble økningen på grunn av at belastningen vises fra LUN-ene til det andre lagringssystemet, og vi går tilbake til samme ytelsesnivå som vi hadde før "fall", men bare innenfor rammen av ett nettsted.
Ved hjelp av kompetent dimensjonering kan du sikre forhold der brukere ikke vil føle feilen til et helt lagringssystem i det hele tatt. Men vi gjentar nok en gang, dette krever veldig nøye dimensjonering, som du forresten kan kontakte oss gratis for :-).
Sette opp en metroklynge
Å sette opp en metrocluster er veldig lik å sette opp vanlig replikering, som vi beskrev i . La oss derfor kun fokusere på forskjellene. Vi setter opp en benk i laboratoriet basert på arkitekturen ovenfor, kun i en minimal versjon: to lagringssystemer koblet via 10G Ethernet, to 10G-svitsjer og en vert som ser gjennom svitsjene på begge lagringssystemene med 10G-porter. Arbiteren kjører på en virtuell maskin.
Når du konfigurerer virtuelle IP-er (VIP-er) for en replika, bør du velge VIP-typen - for metrocluster.
Vi opprettet to replikeringskoblinger for to LUN-er og distribuerte dem over to lagringssystemer: LUN TEST Primær på lagringssystem 1 (METRO-kobling), LUN TEST2 Primær for lagringssystem 2 (METRO2-kobling).
For dem konfigurerte vi to identiske mål (i vårt tilfelle iSCSI, men FC støttes også, oppsettslogikken er den samme).
Lagringssystem 1:
Lagringssystem 2:
For replikeringsforbindelser ble det laget tilordninger på hvert lagringssystem.
Lagringssystem 1:
Lagringssystem 2:
Vi satte opp multipath og presenterte det for verten.
Sette opp en voldgiftsdommer
Du trenger ikke å gjøre noe spesielt med selve dommeren; du trenger bare å aktivere den på den tredje siden, gi den en IP og konfigurere tilgang til den via ICMP og SSH. Selve oppsettet utføres fra selve lagringssystemene. I dette tilfellet er det nok å konfigurere arbiteren én gang på en av lagringskontrollerne i metroclusteret; disse innstillingene vil bli distribuert til alle kontrollere automatisk.
I seksjonen Ekstern replikering>> Metrocluster (på hvilken som helst kontroller)>> "Konfigurer"-knappen.
Vi legger inn IP-en til dommeren, samt kontrollgrensesnittene til to fjernlagringskontrollere.
Etter dette må du aktivere alle tjenester («Start alt på nytt»-knappen). Hvis de rekonfigureres i fremtiden, må tjenestene startes på nytt for at innstillingene skal tre i kraft.
Vi sjekker at alle tjenester kjører.
Dette fullfører metrocluster-oppsettet.
Kollisjonstest
Krasjtesten i vårt tilfelle vil være ganske enkel og rask, siden replikeringsfunksjonaliteten (bytte, konsistens osv.) ble diskutert i . Derfor, for å teste påliteligheten til metroklyngen, er det nok for oss å sjekke automatiseringen av feildeteksjon, bytte og fravær av opptakstap (I/O-stopp).
For å gjøre dette, emulerer vi en fullstendig feil i et av lagringssystemene ved fysisk å slå av begge kontrollerene, etter først å ha begynt å kopiere en stor fil til LUN, som må aktiveres på det andre lagringssystemet.
Deaktiver ett lagringssystem. På det andre lagringssystemet ser vi varsler og meldinger i loggene om at forbindelsen med nabosystemet er tapt. Hvis varsler via SMTP- eller SNMP-overvåking er konfigurert, vil administratoren motta tilsvarende varsler.
Nøyaktig 10 sekunder senere (synlig på begge skjermbildene) ble METRO-replikeringsforbindelsen (den som var Primær på det mislykkede lagringssystemet) automatisk Primær på det fungerende lagringssystemet. Ved å bruke den eksisterende kartleggingen forble LUN TEST tilgjengelig for verten, opptaket sank litt (innenfor de lovede 10 prosentene), men ble ikke avbrutt.
Testen ble fullført.
Oppsummering
Den nåværende implementeringen av metrocluster i AERODISK Engine N-seriens lagringssystemer tillater fullt ut å løse problemer der det er nødvendig å eliminere eller minimere nedetid for IT-tjenester og sikre driften 24/7/365 med minimale arbeidskostnader.
Vi kan selvfølgelig si at alt dette er teori, ideelle laboratorieforhold og så videre... MEN vi har en rekke implementerte prosjekter der vi har implementert katastrofebestandighetsfunksjonalitet, og systemene fungerer perfekt. En av våre ganske kjente kunder, som bruker bare to lagringssystemer i en katastrofesikker konfigurasjon, har allerede sagt ja til å publisere informasjon om prosjektet, så i neste del vil vi snakke om kampimplementeringen.
Takk, vi ser frem til en produktiv diskusjon.
Kilde: www.habr.com