Hej Habr læsere! I den sidste artikel talte vi om et simpelt middel til gendannelse af katastrofer i AERODISK ENGINE-lagringssystemer - replikering. I denne artikel vil vi dykke ned i et mere komplekst og interessant emne - en metrocluster, det vil sige et automatiseret katastrofebeskyttelsesværktøj til to datacentre, der gør det muligt for datacentre at arbejde i aktiv-aktiv tilstand. Vi vil fortælle, vise, bryde og ordne.
Som sædvanlig i begyndelsen af teorien
En metroklynge er en klynge fordelt på flere steder i en by eller et distrikt. Ordet "klynge" antyder klart for os, at komplekset er automatiseret, det vil sige, at skift af klynge noder i tilfælde af fejl (failover) sker automatisk.
Det er her den største forskel mellem en metroklynge og almindelig replikering ligger. Automatisering af operationer. Det vil sige, at i tilfælde af visse hændelser (svigt i datacenteret, brud på kanaler osv.), vil lagersystemet selvstændigt udføre de nødvendige handlinger for at opretholde datatilgængeligheden. Når du bruger almindelige replikaer, udføres disse handlinger helt eller delvist manuelt af administratoren.
Hvad gør det?
Hovedmålet for kunder, der bruger visse metrocluster-implementeringer, er at minimere RTO (Recovery Time Objective). Det vil sige at minimere gendannelsestiden for it-tjenester efter en fejl. Hvis du bruger konventionel replikering, vil genoprettelsestiden altid være længere end genoprettelsestiden med en metroklynge. Hvorfor? Meget simpelt. Administratoren skal være på arbejdspladsen og skifte replikering manuelt, mens metroklyngen gør dette automatisk.
Hvis du ikke har en dedikeret vagtadministrator, der ikke sover, ikke spiser, ikke ryger eller bliver syg, men ser på lagersystemets tilstand 24 timer i døgnet, så er der ingen måde at garantere, at administratoren vil være tilgængelig for manuel skift under en fejl.
I overensstemmelse hermed vil RTO i fravær af en metroklynge eller en udødelig administrator på 99. niveau af administratorernes vagttjeneste være lig med summen af koblingstiden for alle systemer og den maksimale tidsperiode, hvorefter administratoren er garanteret at begynde at arbejde med lagersystemet og relaterede systemer.
Dermed kommer vi frem til den oplagte konklusion, at metroklyngen skal bruges, hvis kravet til RTO er minutter, ikke timer eller dage.Det vil sige, når IT-afdelingen i tilfælde af det værste fald i datacentret skal give forretningen en tid til at genoprette adgangen til it-tjenester inden for få minutter eller endda sekunder.
Hvordan fungerer det?
På det lavere niveau bruger metroklyngen den synkrone datareplikeringsmekanisme, som vi beskrev i den forrige artikel (se nedenfor). ). Da replikering er synkron, er kravene til det passende, eller rettere:
- fiber som fysik, 10 gigabit ethernet (eller højere);
- afstanden mellem datacentre er ikke mere end 40 kilometer;
- optisk kanalforsinkelse mellem datacentre (mellem lagersystemer) op til 5 millisekunder (optimalt 2).
Alle disse krav er af rådgivende karakter, det vil sige, at metroklyngen fungerer, selvom disse krav ikke er opfyldt, men det skal forstås, at konsekvenserne af manglende overholdelse af disse krav er lig med at bremse driften af begge lagersystemer i metroklyngen.
Så en synkron replika bruges til at overføre data mellem lagersystemer, men hvordan skifter replikaer automatisk, og vigtigst af alt, hvordan undgår man split-brain? For at gøre dette, på niveauet ovenfor, bruges en ekstra enhed - dommeren.
Hvordan fungerer en voldgiftsdommer, og hvad er hans opgave?
Mægleren er en lille virtuel maskine eller en hardwareklynge, der skal lanceres på et tredje sted (for eksempel på et kontor) og give adgang til lager via ICMP og SSH. Efter start skal dommeren indstille IP'en og derefter angive dens adresse fra lagersiden plus adresserne på fjernbetjeningerne, der deltager i metroklyngen. Herefter er dommeren klar til at gå.
Voldgiftsdommeren overvåger konstant alle lagersystemer i metroklyngen, og i tilfælde af, at et bestemt lagersystem er utilgængeligt, beslutter han sig efter bekræftelse af utilgængelighed fra et andet klyngemedlem (et af de "live" lagersystemer), at starte proceduren for at skifte replikeringsregler og kortlægning.
En meget vigtig pointe. Dommeren skal altid være placeret på et andet sted end dem, hvor lagersystemerne er placeret, det vil sige hverken i DPC 1, hvor lager 1 er placeret, eller i DPC 2, hvor lager 2 er installeret.
Hvorfor? For kun på denne måde kan dommeren ved hjælp af et af de overlevende lagersystemer entydigt og præcist bestemme faldet på et hvilket som helst af de to steder, hvor lagersystemerne er installeret. Enhver anden måde at placere en voldgiftsdommer på kan resultere i en splittet hjerne.
Lad os nu dykke ned i detaljerne om dommerens job.
Adskillige tjenester kører på arbiteren, der konstant poller alle lagercontrollere. Hvis resultatet af afstemningen afviger fra den foregående (tilgængelig/utilgængelig), så skrives det til en lille database, der også fungerer på arbiteren.
Overvej dommerens logik mere detaljeret.
Trin 1. Bestemmelse af utilgængelighed. En hændelse, der signalerer en lagersystemfejl, er fraværet af et ping fra begge controllere i det samme lagersystem i 5 sekunder.
Trin 2. Start af omskiftningsproceduren. Efter at voldgiftsdommeren indså, at et af lagersystemerne ikke er tilgængeligt, sender han en anmodning til "live" lagersystemet for at sikre sig, at det "døde" lagersystem virkelig er dødt.
Efter at have modtaget en sådan kommando fra voldgiftsdommeren, kontrollerer det andet (levende) lagersystem yderligere tilgængeligheden af det faldne første lagersystem og sender, hvis ikke, voldgiftsdommeren bekræftelse af sit gæt. SHD er faktisk ikke tilgængelig.
Efter at have modtaget en sådan bekræftelse, starter voldgiftsdommeren en fjernprocedure for at skifte replikering og hæve kortlægningen på de replikaer, der var aktive (primære) på det faldne lagersystem, og sender en kommando til det andet lagersystem om at lave disse replikaer fra sekundære til primære og hæve mappingen. Nå, det andet lagersystem udfører disse procedurer, hvorefter det giver adgang til de tabte LUN'er fra sig selv.
Hvorfor er der behov for yderligere verifikation? For kvorum. Det vil sige, at størstedelen af det samlede ulige (3) antal af klyngemedlemmer skal bekræfte faldet af en af klyngens noder. Først da vil denne beslutning være helt rigtig. Dette er nødvendigt for at undgå fejlagtig skift og følgelig split-brain.
Trin 2 tager omkring 5-10 sekunder i tid, så under hensyntagen til den tid, der kræves for at fastslå utilgængelighed (5 sekunder), inden for 10-15 sekunder efter fejlen, vil LUN'er med et faldet lagersystem automatisk være tilgængelige til at arbejde med live storage.
Det er klart, at for at undgå afbrydelser med værter, skal du også sørge for den korrekte indstilling af timeouts på værterne. Den anbefalede timeout er mindst 30 sekunder. Dette forhindrer værten i at afbryde forbindelsen til lageret under en failover-belastning og kan sikre, at der ikke er nogen I/O-afbrydelse.
Vent et øjeblik, det viser sig, at hvis alt er fint med metroklyngen, hvorfor har vi så overhovedet brug for regelmæssig replikering?
Faktisk er alt ikke så simpelt.
Overvej fordele og ulemper ved metroklyngen
Så vi indså, at de åbenlyse fordele ved metroklyngen sammenlignet med konventionel replikering er:
- Fuld automatisering, der sikrer minimal genopretningstid i tilfælde af en katastrofe;
- Og det er det :-).
Og nu, opmærksomhed, ulemper:
- Løsningsomkostninger. Selvom metroclusteret i Aerodisk-systemer ikke kræver yderligere licenser (den samme licens bruges som til replikaen), vil omkostningerne ved løsningen stadig være endnu højere end ved brug af synkron replikering. Du skal implementere alle kravene til en synkron replika, plus kravene til metroklyngen, der er forbundet med yderligere omskiftning og yderligere lokalitet (se planlægning af metroklynge);
- Beslutningens kompleksitet. En metroklynge er meget mere kompleks end en almindelig replika og kræver meget mere opmærksomhed og indsats for at planlægge, konfigurere og dokumentere.
Til sidst. Metrocluster er bestemt en meget teknologisk og god løsning, når du virkelig skal levere RTO på få sekunder eller minutter. Men hvis der ikke er en sådan opgave, og RTO i timer er OK for erhvervslivet, så giver det ingen mening at skyde spurve fra en kanon. Den sædvanlige arbejder-bonde-replikering er nok, da metroklyngen vil forårsage ekstra omkostninger og komplikation af IT-infrastrukturen.
Metroklyngeplanlægning
Dette afsnit foregiver ikke at være en omfattende tutorial om design af metroklynge, men viser kun de vigtigste retninger, der bør udarbejdes, hvis du beslutter dig for at bygge et sådant system. Sørg derfor under selve implementeringen af metroklyngen for at inddrage producenten af lagersystemet (det vil sige os) og andre relaterede systemer til høring.
Spillesteder
Som nævnt ovenfor kræver en metroklynge minimum tre pladser. To datacentre, hvor lagringssystemer og relaterede systemer vil fungere, samt et tredje sted, hvor dommeren skal arbejde.
Den anbefalede afstand mellem datacentre er ikke mere end 40 kilometer. En større afstand vil med stor sandsynlighed forårsage yderligere forsinkelser, hvilket er meget uønsket i tilfælde af en metroklynge. Husk, at forsinkelser bør være op til 5 millisekunder, selvom det er ønskeligt at holde sig inden for 2.
Forsinkelser anbefales også at blive kontrolleret under planlægningsprocessen. Enhver mere eller mindre voksen udbyder, der leverer fiber mellem datacentre, kan ret hurtigt organisere et kvalitetstjek.
Hvad angår forsinkelserne til voldgiftsdommeren (det vil sige mellem det tredje sted og de to første), er den anbefalede forsinkelsestærskel op til 200 millisekunder, det vil sige, at en almindelig virksomheds VPN-forbindelse over internettet vil klare sig.
Skift og netværk
I modsætning til replikeringsordningen, hvor det er nok at forbinde lagersystemer fra forskellige steder, kræver metroklyngeordningen, at værter forbindes til begge lagersystemer på forskellige steder. For at gøre det tydeligere, hvad forskellen er, er begge ordninger anført nedenfor.
Som du kan se på diagrammet, har vi værter for site 1, der kigger på både lagersystem 1 og lagersystem 2. Tværtimod ser værter på site 2 på både lagersystem 2 og lagersystem 1. Det vil sige, at hver vært ser begge lagersystemer. Det er en forudsætning for driften af metroklyngen.
Selvfølgelig er der ingen grund til at trække hver vært med en optisk ledning til et andet datacenter, der vil ikke være nok porte og ledninger. Alle disse forbindelser skal foretages via Ethernet 10G+ eller FibreChannel 8G+ switche (FC kun til tilslutning af værter og lager til IO, replikeringskanalen er i øjeblikket kun tilgængelig over IP (Ethernet 10G+).
Nu et par ord om netværkstopologien. Et vigtigt punkt er den korrekte konfiguration af undernet. Du skal straks definere flere undernet for følgende typer trafik:
- Undernet til replikering, over hvilket data vil blive synkroniseret mellem lagersystemer. Der kan være flere af dem, i dette tilfælde er det ligegyldigt, det hele afhænger af den nuværende (allerede implementerede) netværkstopologi. Hvis der er to af dem, så skal routing mellem dem naturligvis konfigureres;
- Lagerundernet, hvorigennem værter vil få adgang til lagerressourcer (hvis det er iSCSI). Der bør være et sådant undernet i hvert datacenter;
- Kontroller undernet, det vil sige tre routbare undernet på tre steder, hvorfra lagring administreres, og dommeren er også placeret der.
Vi overvejer ikke undernet til at få adgang til værtsressourcer her, da de er meget afhængige af opgaver.
Adskillelse af forskellig trafik over forskellige undernet er ekstremt vigtig (det er især vigtigt at adskille replikaen fra I/O), for hvis du blander al trafikken i ét "tykt" undernet, så vil denne trafik være umulig at administrere, og under betingelserne for to datacentre kan dette stadig forårsage forskellige typer netværkskollisioner. Vi vil ikke dykke dybt ned i dette problem inden for rammerne af denne artikel, da du kan læse om planlægning af et netværk strakt mellem datacentre på ressourcer hos producenter af netværksudstyr, hvor dette er beskrevet meget detaljeret.
Arbiter konfiguration
Voldgiftsdommeren skal give adgang til alle styregrænseflader i lagersystemet via ICMP- og SSH-protokoller. Du bør også tænke på dommerens fejltolerance. Der er en nuance her.
Arbiter failover er yderst ønskeligt, men ikke påkrævet. Og hvad sker der, hvis voldgiftsdommeren styrter ned på det forkerte tidspunkt?
- Driften af metroklyngen i normal tilstand ændres ikke, fordi arbtir påvirker ikke driften af metroklyngen i normal tilstand på nogen måde (dens opgave er at skifte belastningen mellem datacentre i tide)
- På samme tid, hvis dommeren af den ene eller anden grund falder og "sover" ulykken i datacentret, så vil der ikke ske nogen skift, fordi der ikke vil være nogen til at give de nødvendige skiftekommandoer og organisere et beslutningsdygtighed. I dette tilfælde vil metroklyngen blive til en almindelig replikeringsordning, som skal skiftes manuelt under en katastrofe, hvilket vil påvirke RTO.
Hvad følger deraf? Hvis du virkelig har brug for at give et minimum RTO, skal du sikre fejltolerancen for dommeren. Der er to muligheder for dette:
- Kør en virtuel maskine med en arbiter på en fejltolerant hypervisor, da alle voksne hypervisorer understøtter fejltolerance;
- Hvis det på den tredje side (på et betinget kontor) er for doven til at installere en normal klynge, og der ikke er nogen eksisterende klynge af hypervisorer, så har vi leveret en hardwareversion af arbiteren, som er lavet i en 2U-boks, hvori to almindelige x-86-servere fungerer, og som kan overleve en lokal fejl.
Vi anbefaler på det kraftigste, at du sikrer arbiterens fejltolerance, på trods af at metroklyngen ikke har brug for det i normal tilstand. Men som både teori og praksis viser, hvis du bygger en virkelig pålidelig katastrofetolerant infrastruktur, så er det bedre at spille det sikkert. Det er bedre at beskytte dig selv og din virksomhed mod "ondskabens lov", det vil sige mod svigt af både voldgiftsdommeren og et af de steder, hvor lagersystemet er placeret.
Løsningsarkitektur
I betragtning af ovenstående krav får vi følgende generelle løsningsarkitektur.
LUN'er bør være jævnt fordelt på de to steder for at undgå alvorlig overbelastning. Samtidig er det, når der skal dimensioneres i begge datacentre, nødvendigt at sørge for ikke kun den dobbelte volumen (som er nødvendig for at gemme data samtidigt på to lagersystemer), men også dobbelt ydeevne i IOPS og MB/s for at forhindre nedbrydning af applikationer i tilfælde af fejl i et af datacentrene.
Separat bemærker vi, at med en korrekt tilgang til dimensionering (det vil sige, forudsat at vi har sørget for de korrekte øvre grænser for IOPS og MB/s, såvel som de nødvendige CPU- og RAM-ressourcer), hvis et af lagersystemerne i metroklyngen svigter, vil der ikke være noget alvorligt fald i ydeevnen i forhold til midlertidigt arbejde på et lagersystem.
Dette forklares af det faktum, at i forhold til to steder, der arbejder samtidigt, "spiser" synkron replikering halvdelen af skriveydelsen, da hver transaktion skal skrives til to lagersystemer (svarende til RAID-1/10). Så hvis et af lagersystemerne fejler, forsvinder effekten af replikering midlertidigt (indtil det fejlslagne lagersystem stiger), og vi får en dobbelt stigning i skriveydeevne. Efter at LUN'erne for det fejlslagne lagringssystem er genstartet på det fungerende lagringssystem, forsvinder denne dobbelte stigning på grund af det faktum, at der er en belastning fra LUN'erne i et andet lagringssystem, og vi vender tilbage til det samme niveau af ydeevne, som vi havde før "efteråret", men kun inden for samme sted.
Ved hjælp af kompetent dimensionering er det muligt at give betingelser, hvor brugerne slet ikke vil føle fejlen i hele opbevaringssystemet. Men endnu en gang kræver dette meget omhyggelig dimensionering, som du i øvrigt kan kontakte os gratis :-).
Opsætning af en metroklynge
Opsætning af en metroklynge minder meget om opsætning af almindelig replikering, som vi beskrev i . Så lad os bare fokusere på forskellene. Vi satte en bænk op i laboratoriet baseret på arkitekturen ovenfor, kun i minimumsversionen: to lagersystemer forbundet via 10G Ethernet til hinanden, to 10G switche og en vært, der kigger gennem switchene til begge lagersystemer med 10G porte. Voldgiftsdommeren kører på en virtuel maskine.
Når du konfigurerer virtuel IP (VIP) til en replika, skal du vælge VIP-typen - for en metroklynge.
Oprettede to replikeringslinks til to LUN'er og distribuerede dem over to lagersystemer: LUN TEST Primary på lager1 (METRO-forbindelse), LUN TEST2 Primary for storage2 (METRO2-forbindelse).
For dem konfigurerede vi to identiske mål (i vores tilfælde iSCSI, men FC understøttes også, konfigurationslogikken er den samme).
opbevaring 1:
opbevaring 2:
Til replikeringslinks blev der lavet kortlægninger på hvert lagersystem.
opbevaring 1:
opbevaring 2:
Vi satte multipath op og præsenterede det for værten.
Opsætning af en dommer
Du behøver ikke at gøre noget særligt med selve arbiteren, du skal bare tænde den på det tredje websted, indstille dens IP og konfigurere adgang til den via ICMP og SSH. Selve konfigurationen udføres fra selve lagersystemerne. Samtidig er det nok at konfigurere arbiteren én gang på en af lagercontrollerne i metroklyngen, disse indstillinger vil automatisk blive distribueret til alle controllere.
Under Fjernreplikering>> Metrocluster (på enhver controller)>> Konfigurer-knap.
Vi indtaster IP-adressen for dommeren, såvel som kontrolgrænsefladerne for de to fjernlagringscontrollere.
Derefter skal du aktivere alle tjenester (knap "Genstart alt"). Hvis du omkonfigurerer i fremtiden, skal tjenesterne genstartes for at indstillingerne træder i kraft.
Vi tjekker, at alle tjenester kører.
Dette fuldender metrocluster-opsætningen.
Crash test
Crashtesten i vores tilfælde vil være ret enkel og hurtig, da replikeringsfunktionaliteten (switching, konsistens osv.) blev overvejet i . Derfor, for at teste pålideligheden af metroklyngen, er det nok for os at kontrollere automatiseringen af ulykkesdetektering, omskiftning og fraværet af skrivetab (I/O-stop).
For at gøre dette efterligner vi en fuldstændig fejl i et af lagersystemerne ved fysisk at slukke for begge dets controllere, efter at have startet kopiering af en stor fil til en LUN, som burde være aktiveret på et andet lagersystem.
Deaktiver ét lagersystem. På det andet lagersystem ser vi advarsler og beskeder i loggene om, at forbindelsen til nabosystemet er forsvundet. Hvis meddelelser via SMTP- eller SNMP-overvågning er konfigureret, vil de relevante meddelelser blive sendt til administratoren.
Præcis 10 sekunder senere (set i begge skærmbilleder) blev METRO-replikeringslinket (det der var Primært på det faldne lagersystem) automatisk Primært på det fungerende lagersystem. Ved at bruge den eksisterende kortlægning forblev LUN TEST tilgængelig for værten, optagelsen faldt lidt (inden for de lovede 10 procent), men stoppede ikke.
Testen blev gennemført.
Sammenfatning
Den nuværende implementering af metroclusteret i AERODISK Engine N-seriens lagersystemer tillader dig fuldt ud at løse problemer, hvor du skal eliminere eller minimere nedetiden for it-tjenester og sikre deres drift i 24/7/365-tilstand med minimale arbejdsomkostninger.
Man kan selvfølgelig sige, at alt dette er teori, ideelle laboratorieforhold og så videre ... MEN vi har en række implementerede projekter, hvor vi implementerede disaster recovery-funktionaliteten, og systemerne fungerer perfekt. En af vores ret velkendte kunder, hvor kun to lagersystemer bruges i en katastrofetolerant konfiguration, har allerede sagt ja til at offentliggøre information om projektet, så i næste del vil vi tale om kampimplementering.
Tak, ser frem til en produktiv diskussion.
Kilde: www.habr.com