Hej Habr-läsare! Ämnet för den här artikeln kommer att vara implementeringen av katastrofåterställningsverktyg i AERODISK Engine-lagringssystem. Från början ville vi skriva i en artikel om båda verktygen: replikering och metrokluster, men tyvärr visade sig artikeln vara för lång, så vi delade upp artikeln i två delar. Låt oss gå från enkla till komplexa. I den här artikeln kommer vi att sätta upp och testa synkron replikering - vi kommer att släppa ett datacenter, och även bryta kommunikationskanalen mellan datacentren och se vad som händer.
Våra kunder ställer oss ofta olika frågor om replikering, så innan vi går vidare till att sätta upp och testa implementeringen av repliker kommer vi att berätta lite om vad replikering i lagring är.
Lite teori
Replikering i lagringssystem är en kontinuerlig process för att säkerställa dataidentitet på flera lagringssystem samtidigt. Tekniskt sett utförs replikering på två sätt.
Synkron replikering – detta är att kopiera data från huvudlagringssystemet till backupsystemet, följt av obligatorisk bekräftelse från båda lagringssystemen att data har registrerats och bekräftats. Det är efter bekräftelse på båda sidor (båda lagringssystemen) som uppgifterna anses registrerade och går att arbeta med. Detta säkerställer garanterad dataidentitet på alla lagringssystem som deltar i repliken.
Fördelarna med denna metod:
- Data är alltid identisk på alla lagringssystem
Nackdelar:
- Hög kostnad för lösningen (snabba kommunikationskanaler, dyr optisk fiber, långvågssändare, etc.)
- Avståndsbegränsningar (inom flera tiotals kilometer)
- Det finns inget skydd mot logisk datakorruption (om data skadas (avsiktligt eller oavsiktligt) på huvudlagringssystemet, kommer det automatiskt och omedelbart att skadas på backupen, eftersom data alltid är identiska (det är paradoxen)
Asynkron replikering – det här är också att kopiera data från huvudlagringssystemet till backupen, men med en viss fördröjning och utan att behöva bekräfta skrivningen på andra sidan. Du kan arbeta med data direkt efter att du har spelat in dem i huvudlagringssystemet, och på backuplagringssystemet kommer data att vara tillgänglig efter en tid. Uppgifternas identitet i detta fall är naturligtvis inte säkerställd alls. Data på backuplagringssystemet är alltid lite "i det förflutna".
Fördelar med asynkron replikering:
- Lågkostnadslösning (alla kommunikationskanaler, optik tillval)
- Inga avståndsbegränsningar
- På backuplagringssystemet försämras inte data om de skadas på huvudet (åtminstone under en tid); om data blir korrupta kan du alltid stoppa repliken för att förhindra datakorruption på backuplagringssystemet
Nackdelar:
- Data i olika datacenter är alltid inte identiska
Således beror valet av replikeringsläge på affärsmål. Om det är kritiskt för dig att backupdatacentret innehåller exakt samma data som huvuddatacentret (dvs. affärskrav för RPO = 0), måste du plocka ut pengarna och stå ut med begränsningarna för en synkron kopia. Och om förseningen i datatillståndet är acceptabel eller det helt enkelt inte finns några pengar, måste du definitivt använda den asynkrona metoden.
Låt oss också separat lyfta fram ett sådant läge (mer exakt, en topologi) som ett metrokluster. I metroklusterläge används synkron replikering, men till skillnad från en vanlig replik tillåter ett metrokluster båda lagringssystemen att arbeta i aktivt läge. De där. du har ingen separation mellan aktiva och standby-datacenter. Applikationer fungerar samtidigt med två lagringssystem som är fysiskt placerade i olika datacenter. Driftstopp vid olyckor i en sådan topologi är mycket små (RTO, vanligtvis minuter). I den här artikeln kommer vi inte att överväga vår implementering av metroklustret, eftersom detta är ett mycket stort och rymligt ämne, så vi kommer att ägna en separat, nästa artikel till det, i fortsättningen av den här.
Mycket ofta, när vi talar om replikering med lagringssystem, har många människor en rimlig fråga: > "Många applikationer har sina egna replikeringsverktyg, varför använda replikering på lagringssystem? Är det bättre eller sämre?
Det finns inget tydligt svar här, så här är argumenten FÖR och NACKDELAR:
Argument FÖR lagringsreplikering:
- Enkelheten i lösningen. Med ett verktyg kan du replikera hela din datamängd, oavsett belastningstyp och applikation. Om du använder en replik från applikationer måste du konfigurera varje applikation separat. Om det finns fler än 2 av dem är detta extremt arbetskrävande och dyrt (applikationsreplikering kräver vanligtvis en separat och inte gratis licens för varje applikation. Men mer om det nedan).
- Du kan replikera vad som helst - vilken applikation som helst, vilken data som helst - och det kommer alltid att vara konsekvent. Många (de flesta) applikationer har inte replikeringsmöjligheter, och repliker från lagringssystemet är det enda sättet att ge skydd mot katastrofer.
- Det finns inget behov av att betala för mycket för applikationsreplikeringsfunktioner. Som regel är det inte billigt, precis som licenser för en kopia av ett lagringssystem. Men du måste betala för en licens för lagringsreplikering en gång, och en licens för applikationsreplik måste köpas för varje applikation separat. Om det finns många sådana applikationer så kostar det en ganska slant och kostnaden för licenser för lagringsreplikering blir en droppe i hinken.
Argument MOT lagringsreplikering:
- Replika genom applikationer har mer funktionalitet ur själva applikationernas synvinkel, applikationen känner sin data bättre (uppenbarligen), så det finns fler alternativ för att arbeta med dem.
- Tillverkare av vissa applikationer garanterar inte att deras data är konsekventa om replikeringen görs med hjälp av tredjepartsverktyg. *
* - kontroversiell avhandling. Till exempel har en välkänd DBMS-tillverkare officiellt deklarerat under mycket lång tid att deras DBMS bara kan replikeras normalt med hjälp av deras medel, och resten av replikeringen (inklusive lagringssystem) är "inte sant." Men livet har visat att det inte är så. Troligtvis (men det är inte säkert) är detta helt enkelt inte det mest ärliga försöket att sälja fler licenser till kunder.
Som ett resultat, i de flesta fall, är replikering från lagringssystemet bättre, eftersom Detta är ett enklare och billigare alternativ, men det finns komplexa fall när specifik applikationsfunktionalitet behövs, och det är nödvändigt att arbeta med applikationsnivåreplikering.
Klar med teorin, öva nu
Vi kommer att konfigurera repliken i vårt labb. Under laboratorieförhållanden emulerade vi två datacenter (i själva verket två intilliggande rack som verkade vara i olika byggnader). Stativet består av två Engine N2 lagringssystem, som är anslutna till varandra med optiska kablar. En fysisk server som kör Windows Server 2016 är ansluten till båda lagringssystemen med 10 Gb Ethernet. Stativet är ganska enkelt, men detta förändrar inte essensen.
Schematiskt ser det ut så här:
Logiskt är replikeringen organiserad enligt följande:
Låt oss nu titta på replikeringsfunktionaliteten som vi har nu.
Två lägen stöds: asynkron och synkron. Det är logiskt att det synkrona läget begränsas av avstånd och kommunikationskanal. I synnerhet kräver synkront läge användning av fiber som fysik och 10 Gigabit Ethernet (eller högre).
Det stödda avståndet för synkron replikering är 40 kilometer, fördröjningsvärdet för den optiska kanalen mellan datacenter är upp till 2 millisekunder. Generellt kommer det att fungera med stora förseningar, men då blir det kraftiga nedgångar under inspelning (vilket också är logiskt), så om du planerar synkron replikering mellan datacenter bör du kontrollera kvaliteten på optiken och förseningarna.
Kraven på asynkron replikering är inte så allvarliga. Mer exakt, de finns inte alls. Alla fungerande Ethernet-anslutningar fungerar.
För närvarande stöder lagringssystemet AERODISK ENGINE replikering för blockenheter (LUN) via Ethernet-protokollet (över koppar eller optiskt). För projekt där replikering genom ett SAN-tyg över Fibre Channel krävs, lägger vi för närvarande till en lämplig lösning, men den är inte klar än, så i vårt fall endast Ethernet.
Replikering kan fungera mellan alla lagringssystem i ENGINE-serien (N1, N2, N4) från juniorsystem till äldre och vice versa.
Funktionaliteten för båda replikeringslägena är helt identisk. Nedan finns mer information om vad som finns tillgängligt:
- Replikering "en till en" eller "en till en", det vill säga den klassiska versionen med två datacenter, huvudet och säkerhetskopian
- Replikering är "en till många" eller "en till många", dvs. ett LUN kan replikeras till flera lagringssystem samtidigt
- Aktivera, inaktivera och "vända" replikering för att aktivera, inaktivera eller ändra replikeringsriktningen
- Replikering är tillgänglig för både RDG (Raid Distributed Group) och DDP (Dynamic Disk Pool) pooler. LUN för en RDG-pool kan dock bara replikeras till en annan RDG. Samma sak med DDP.
Det finns många fler små funktioner, men det finns ingen speciell mening med att lista dem, vi kommer att nämna dem när vi ställer in dem.
Konfigurera replikering
Installationsprocessen är ganska enkel och består av tre steg.
- Nätverkskonfiguration
- Lagringsinställningar
- Uppsättning av regler (anslutningar) och kartläggning
En viktig punkt vid inställning av replikering är att de två första stegen ska upprepas på fjärrlagringssystemet, det tredje steget - bara på det huvudsakliga.
Konfigurera nätverksresurser
Det första steget är att konfigurera nätverksportarna genom vilka replikeringstrafik ska överföras. För att göra detta måste du aktivera portarna och ställa in deras IP-adresser i avsnittet Front-end-adaptrar.
Efter detta måste vi skapa en pool (i vårt fall RDG) och en virtuell IP för replikering (VIP). VIP är en flytande IP-adress som är bunden till två "fysiska" adresser för lagringskontroller (portarna som vi just konfigurerat). Detta kommer att vara huvudreplikeringsgränssnittet. Du kan också arbeta inte med en VIP, utan med ett VLAN, om du behöver arbeta med taggad trafik.
Processen att skapa en VIP för en replik skiljer sig inte mycket från att skapa en VIP för I/O (NFS, SMB, iSCSI). I det här fallet skapar vi en vanlig VIP (utan VLAN), men se till att ange att den är för replikering (utan denna pekare kommer vi inte att kunna lägga till VIP till regeln i nästa steg).
VIP-enheten måste vara i samma subnät som de IP-portar som den flyter mellan.
Vi upprepar dessa inställningar på ett fjärrlagringssystem, med en annan IP, naturligtvis.
VIPs från olika lagringssystem kan finnas i olika subnät, huvudsaken är att det finns routing mellan dem. I vårt fall visas detta exempel exakt (192.168.3.XX och 192.168.2.XX)
Detta slutför förberedelsen av nätverksdelen.
Konfigurera lagring
Att ställa in lagring för en replik skiljer sig från vanligt endast genom att vi gör mappningen via en speciell meny "Replication Mapping". Annars är allt detsamma som med den vanliga inställningen. Nu i ordning.
I den tidigare skapade poolen R02 måste du skapa ett LUN. Låt oss skapa det och kalla det LUN1.
Vi måste också skapa samma LUN på ett fjärrlagringssystem av identisk storlek. Vi skapar. För att undvika förvirring, låt oss ringa fjärrkontrollen LUN LUN1R
Om vi behövde ta ett LUN som redan finns, då när vi ställer in repliken, skulle vi behöva avmontera detta produktiva LUN från värden och helt enkelt skapa ett tomt LUN av identisk storlek på fjärrlagringssystemet.
Lagringsinstallationen är klar, låt oss gå vidare till att skapa en replikeringsregel.
Konfigurera replikeringsregler eller replikeringslänkar
Efter att ha skapat LUN på lagringssystemet, som kommer att vara det primära för tillfället, konfigurerar vi replikeringsregeln LUN1 på lagringssystem 1 till LUN1R på lagringssystem 2.
Inställningen görs i menyn "Fjärrreplikering".
Låt oss skapa en regel. För att göra detta måste du ange mottagaren av repliken. Där ställer vi även in namnet på anslutningen och typen av replikering (synkron eller asynkron).
I fältet "fjärrsystem" lägger vi till vårt lagringssystem2. För att lägga till måste du använda hanterings-IP-lagringssystemen (MGR) och namnet på fjärr-LUN som vi kommer att utföra replikering i (i vårt fall, LUN1R). Kontroll-IP:er behövs endast vid tillägg av en anslutning; replikeringstrafik kommer inte att överföras genom dem; den tidigare konfigurerade VIP kommer att användas för detta.
Redan i detta skede kan vi lägga till mer än ett fjärrsystem för "en till många"-topologin: klicka på knappen "lägg till nod", som i bilden nedan.
I vårt fall finns det bara ett fjärrsystem, så vi begränsar oss till detta.
Regeln är klar. Observera att det läggs till automatiskt på alla replikeringsdeltagare (i vårt fall är det två av dem). Du kan skapa så många sådana regler som du vill, för valfritt antal LUN:er och i vilken riktning som helst. Till exempel, för att balansera belastningen, kan vi replikera en del av LUN:erna från lagringssystem 1 till lagringssystem 2, och den andra delen, tvärtom, från lagringssystem 2 till lagringssystem 1.
Förvaringssystem 1. Omedelbart efter skapandet började synkroniseringen.
Förvaringssystem 2. Vi ser samma regel, men synkroniseringen har redan avslutats.
LUN1 på lagringssystem 1 är i den primära rollen, det vill säga den är aktiv. LUN1R på lagringssystem 2 är i rollen som sekundärt, det vill säga den är i standby om lagringssystem 1 misslyckas.
Nu kan vi koppla vårt LUN till värden.
Vi kommer att ansluta via iSCSI, även om det också kan göras via FC. Att ställa in mappning via iSCSI LUN i en replik skiljer sig praktiskt taget inte från det vanliga scenariot, så vi kommer inte att överväga detta i detalj här. Om något beskrivs denna process i artikeln "".
Den enda skillnaden är att vi skapar mappning i menyn "Replication Mapping".
Vi satte upp kartläggning och gav LUN till värden. Värden såg LUN.
Vi formaterar det till ett lokalt filsystem.
Det var allt, installationen är klar. Tester kommer härnäst.
testning
Vi kommer att testa tre huvudscenarier.
- Vanligt rollbyte Sekundär > Primär. Regelbundet rollbyte behövs om vi till exempel behöver utföra vissa förebyggande operationer i huvuddatacentret och under denna tid, för att data ska vara tillgänglig, överför vi belastningen till backupdatacentret.
- Emergency roll switching Sekundär > Primär (datacenterfel). Detta är huvudscenariot för vilket replikering existerar, vilket kan hjälpa till att överleva ett fullständigt datacenterfel utan att stoppa företaget under en längre period.
- Nedbrytning av kommunikationskanaler mellan datacenter. Kontrollera att två lagringssystem fungerar korrekt under förhållanden där kommunikationskanalen mellan datacentren av någon anledning inte är tillgänglig (till exempel en grävmaskin som grävde på fel ställe och bröt den mörka optiken).
Först kommer vi att börja skriva data till vårt LUN (skriva filer med slumpmässiga data). Vi ser direkt att kommunikationskanalen mellan lagringssystemen utnyttjas. Detta är lätt att förstå om du öppnar belastningsövervakningen av portarna som är ansvariga för replikering.
Båda lagringssystemen har nu "användbar" data, vi kan börja testet.
För säkerhets skull, låt oss titta på hashsummorna för en av filerna och skriva ner dem.
Regelbundet rollbyte
Funktionen för att byta roller (ändra replikeringsriktningen) kan göras med vilket lagringssystem som helst, men du måste fortfarande gå till båda, eftersom du måste inaktivera mappning på primär och aktivera den på sekundär (som kommer att bli primär ).
Kanske uppstår en rimlig fråga nu: varför inte automatisera detta? Svaret är: det är enkelt, replikering är ett enkelt sätt att motstå katastrofer, baserat enbart på manuella operationer. För att automatisera dessa operationer finns det ett metroklusterläge; det är helt automatiserat, men dess konfiguration är mycket mer komplicerad. Vi kommer att skriva om att skapa ett metrokluster i nästa artikel.
På huvudlagringssystemet inaktiverar vi mappning för att säkerställa att inspelningen stoppas.
Sedan på ett av lagringssystemen (det spelar ingen roll, på huvudet eller säkerhetskopian) i menyn "Fjärrreplikering", välj vår anslutning REPL1 och klicka på "Ändra roll".
Efter några sekunder blir LUN1R (backup storage system) Primär.
Vi kartlägger LUN1R med lagringssystem2.
Efter detta kopplas vår E:-enhet automatiskt till värden, men den här gången "kom" den från LUN1R.
För säkerhets skull jämför vi hashsummorna.
Identiskt. Avklarat prov.
Failover. Datacenterfel
För tillfället är huvudlagringssystemet efter regelbunden växling lagringssystem 2 respektive LUN1R. För att efterlikna en olycka kommer vi att stänga av strömmen på båda lagringskontrollerna2.
Det finns ingen tillgång till den längre.
Låt oss se vad som händer på lagringssystem 1 (det säkerhetskopierade just nu).
Vi ser att den primära LUN (LUN1R) inte är tillgänglig. Ett felmeddelande dök upp i loggarna, i informationspanelen och även i själva replikeringsregeln. Följaktligen är data från värden för närvarande inte tillgänglig.
Ändra rollen för LUN1 till Primär.
Jag gör kartläggning till värden.
Se till att enhet E visas på värden.
Vi kollar hash.
Allt är bra. Lagringssystemet överlevde framgångsrikt fallet av datacentret, som var aktivt. Den ungefärliga tiden vi ägnade åt att ansluta replikeringen "omvändning" och ansluta LUN från backupdatacentret var cirka 3 minuter. Det är tydligt att i verklig produktion är allt mycket mer komplicerat, och förutom åtgärder med lagringssystem måste du utföra många fler operationer på nätverket, på värdar, i applikationer. Och i livet kommer denna tidsperiod att vara mycket längre.
Här skulle jag vilja skriva att allt, testet har slutförts framgångsrikt, men låt oss inte skynda oss. Huvudlagringssystemet "ljuger", vi vet att när det "föll" var det i primärrollen. Vad händer om den plötsligt slås på? Det kommer att finnas två primära roller, vilket motsvarar datakorruption? Låt oss kolla det nu.
Låt oss plötsligt slå på det underliggande lagringssystemet.
Den laddas i några minuter och återgår sedan till tjänst efter en kort synkronisering, men i rollen som sekundär.
Allt ok. Split-brain hände inte. Vi tänkte på detta, och alltid efter ett fall höjs lagringssystemet till rollen som sekundär, oavsett vilken roll det var i "under livet." Nu kan vi med säkerhet säga att testet av datacenterfel var framgångsrikt.
Fel i kommunikationskanaler mellan datacenter
Huvuduppgiften för detta test är att se till att lagringssystemet inte börjar agera konstigt om det tillfälligt tappar kommunikationskanaler mellan två lagringssystem och sedan dyker upp igen.
Så. Vi kopplar bort ledningarna mellan lagringssystemen (låt oss föreställa oss att de grävdes av en grävmaskin).
På Primär ser vi att det inte finns något samband med Secondary.
På Secondary ser vi att det inte finns något samband med Primary.
Allt fungerar bra, och vi fortsätter att skriva data till huvudlagringssystemet, det vill säga att de garanterat skiljer sig från backupen, det vill säga de har "separerats".
På några minuter ”reparerar” vi kommunikationskanalen. Så snart lagringssystemen ser varandra aktiveras datasynkroniseringen automatiskt. Här krävs inget från administratören.
Efter en tid är synkroniseringen klar.
Anslutningen återställdes, förlusten av kommunikationskanaler orsakade inga nödsituationer, och efter påslagning skedde synkroniseringen automatiskt.
Resultat
Vi analyserade teorin - vad behövs och varför, var finns fördelarna och var finns nackdelarna. Sedan sätter vi upp synkron replikering mellan två lagringssystem.
Därefter genomfördes grundläggande tester för normal omkoppling, datacenterfel och kommunikationskanalfel. I samtliga fall fungerade lagringssystemet bra. Det finns ingen dataförlust och administrativ verksamhet hålls till ett minimum för ett manuellt scenario.
Nästa gång kommer vi att komplicera situationen och visa hur all denna logik fungerar i ett automatiserat metrokluster i aktivt-aktivt läge, det vill säga när båda lagringssystemen är primära, och beteendet vid lagringssystemfel är helt automatiserat.
Skriv gärna kommentarer, vi tar gärna emot god kritik och praktiska råd.
Vi ses.
Källa: will.com