Hej Habr-läsare! I den förra artikeln pratade vi om ett enkelt sätt att återställa katastrofer i AERODISK ENGINE-lagringssystem - replikering. I den här artikeln kommer vi att dyka in i ett mer komplext och intressant ämne - metroklustret, det vill säga ett sätt för automatiskt katastrofskydd för två datacenter, vilket gör att datacenter kan arbeta i aktivt-aktivt läge. Vi ska berätta för dig, visa dig, slå sönder det och fixa det.
Som vanligt, teori först
Ett metrokluster är ett kluster spritt över flera platser inom en stad eller region. Ordet "kluster" antyder tydligt för oss att komplexet är automatiserat, det vill säga att byte av klusternoder i händelse av fel sker automatiskt.
Det är här den största skillnaden mellan ett metrokluster och vanlig replikering ligger. Automatisering av driften. Det vill säga, i händelse av vissa incidenter (datacenterfel, trasiga kanaler, etc.), kommer lagringssystemet självständigt att utföra nödvändiga åtgärder för att upprätthålla datatillgänglighet. När du använder vanliga repliker utförs dessa åtgärder helt eller delvis manuellt av administratören.
Vad gör det?
Huvudmålet som kunder eftersträvar när de använder vissa metroklusterimplementationer är att minimera RTO (Recovery Time Objective). Det vill säga att minimera återställningstiden för IT-tjänster efter ett fel. Om du använder vanlig replikering kommer återställningstiden alltid att vara längre än återställningstiden med ett metrokluster. Varför? Väldigt enkelt. Administratören måste vara vid sitt skrivbord och byta replikering manuellt, och metroklustret gör detta automatiskt.
Om du inte har en dedikerad administratör i tjänst som inte sover, inte äter, inte röker eller blir sjuk och som tittar på lagringssystemets tillstånd 24 timmar om dygnet, så finns det inget sätt att garantera att administratören kommer att vara tillgänglig för manuell växling vid fel.
Följaktligen kommer RTO i frånvaro av ett metrokluster eller en odödlig administratör på 99:e nivån av administratörstjänsten att vara lika med summan av kopplingstiden för alla system och den maximala tidsperioden efter vilken administratören garanteras börja arbeta med lagringssystem och relaterade system.
Därmed kommer vi till den självklara slutsatsen att metroklustret bör användas om kravet på RTO är minuter, inte timmar eller dagar, det vill säga när vid värsta datacenterhaveri ska IT-avdelningen förse verksamheten med tid för att återställa åtkomst till IT-tjänster inom några minuter, eller till och med sekunder.
Hur fungerar det?
På den lägre nivån använder metroklustret en mekanism för synkron datareplikering, som vi beskrev i föregående artikel (se. ). Eftersom replikering är synkron är kraven för den motsvarande, eller snarare:
- optisk fiber som fysik, 10 gigabit Ethernet (eller högre);
- avståndet mellan datacenter är inte mer än 40 kilometer;
- optisk kanalfördröjning mellan datacenter (mellan lagringssystem) är upp till 5 millisekunder (optimalt 2).
Alla dessa krav är av rådgivande karaktär, det vill säga metroklustret kommer att fungera även om dessa krav inte uppfylls, men vi måste förstå att konsekvenserna av att dessa krav inte efterlevs är lika med en nedgång i driften av båda lagringssystemen i metroklustret.
Så, en synkron replika används för att överföra data mellan lagringssystem, och hur växlar repliker automatiskt och, viktigast av allt, hur undviker man split-brain? För att göra detta, på en högre nivå, används en ytterligare enhet - en skiljedomare.
Hur fungerar en skiljedomare och vad är hans uppgift?
Medlaren är en liten virtuell maskin eller ett hårdvarukluster som måste startas på en tredje plats (till exempel på ett kontor) och ge tillgång till lagringssystemet via ICMP och SSH. Efter lanseringen bör medlaren ställa in IP:n och sedan från lagringssidan ange dess adress, plus adresserna till fjärrkontroller som deltar i metroklustret. Efter detta är domaren redo att arbeta.
Medlaren övervakar ständigt alla lagringssystem i metroklustret och om ett visst lagringssystem inte är tillgängligt, efter att ha bekräftat otillgängligheten från en annan medlem av klustret (ett av de "live" lagringssystemen), bestämmer han sig för att starta proceduren för att byta replikeringsregler och kartläggning.
En mycket viktig punkt. Skiljemannen måste alltid vara placerad på en annan plats än den där lagringssystemen finns, det vill säga varken i datacenter 1, där lagringssystem 1 är installerat, eller i datacenter 2, där lagringssystem 2 är installerat.
Varför? Eftersom detta är det enda sättet som en skiljedomare, med hjälp av ett av de överlevande lagringssystemen, entydigt och exakt kan fastställa fallet för någon av de två platser där lagringssystemen är installerade. Alla andra metoder för att placera en arbiter kan resultera i en split-brain.
Låt oss nu dyka in i detaljerna i skiljemannens arbete.
Medlaren kör flera tjänster som ständigt pollar alla lagringskontroller. Om omröstningsresultatet skiljer sig från det föregående (tillgängligt/inte tillgängligt), så registreras det i en liten databas, som också fungerar på arbitern.
Låt oss titta mer i detalj på logiken i skiljemannens arbete.
Steg 1: Fastställ otillgänglighet. En lagringssystemfelhändelse är frånvaron av ping från båda kontrollerna i samma lagringssystem inom 5 sekunder.
Steg 2. Starta växlingsproceduren. Efter att skiljedomaren har insett att ett av lagringssystemen är otillgängligt, skickar han en begäran till "live" lagringssystemet för att försäkra sig om att det "döda" lagringssystemet verkligen är dött.
Efter att ha mottagit ett sådant kommando från skiljedomaren kontrollerar det andra (live) lagringssystemet dessutom tillgängligheten för det fallna första lagringssystemet och, om det inte finns där, skickar det en bekräftelse till domaren om sin gissning. Lagringssystemet är verkligen inte tillgängligt.
Efter att ha mottagit en sådan bekräftelse startar medlaren en fjärrprocedur för att byta replikering och höja mappning på de repliker som var aktiva (primära) på det fallna lagringssystemet, och skickar ett kommando till det andra lagringssystemet för att ändra dessa repliker från sekundära till primära och höja kartläggningen. Tja, det andra lagringssystemet utför följaktligen dessa procedurer och ger sedan åtkomst till de förlorade LUN:erna från sig själv.
Varför behövs ytterligare verifiering? För kvorum. Det vill säga, en majoritet av det totala udda (3) antalet klustermedlemmar måste bekräfta fallet av en av klusternoderna. Först då kommer detta beslut att vara definitivt korrekt. Detta är nödvändigt för att undvika felaktig växling och följaktligen split-brain.
Tidssteg 2 tar cirka 5 - 10 sekunder, så med hänsyn till den tid som krävs för att fastställa otillgänglighet (5 sekunder), inom 10 - 15 sekunder efter olyckan, kommer LUN från det fallna lagringssystemet att vara automatiskt tillgängliga för att arbeta med live lagringssystem.
Det är tydligt att för att undvika att tappa anslutningar med värdar måste du också se till att korrekt konfigurera timeouts på värdarna. Rekommenderad timeout är minst 30 sekunder. Detta förhindrar värden från att bryta anslutningen till lagringssystemet under lastväxling i händelse av en katastrof och kan säkerställa att det inte finns några I/O-avbrott.
Vänta lite, det visar sig att om allt är så bra med metroklustret, varför behöver vi överhuvudtaget regelbunden replikering?
I verkligheten är allt inte så enkelt.
Låt oss överväga för- och nackdelarna med metroklustret
Så vi insåg att de uppenbara fördelarna med metroklustret jämfört med konventionell replikering är:
- Full automatisering, säkerställer minimal återhämtningstid i händelse av en katastrof;
- Det är allt :-).
Och nu, uppmärksamhet, nackdelarna:
- Lösningskostnad. Även om metroklustret i Aerodisk-system inte kräver ytterligare licensiering (samma licens används som för repliken) kommer kostnaden för lösningen fortfarande att vara ännu högre än att använda synkron replikering. Du kommer att behöva implementera alla krav för en synkron replika, plus kraven för metrokluster som är förknippade med ytterligare byte och ytterligare plats (se metroklusterplanering);
- Lösningens komplexitet. Metroklustret är mycket mer komplext än en vanlig replik och kräver mycket mer uppmärksamhet och ansträngning för planering, konfiguration och dokumentation.
Så småningom. Metrocluster är verkligen en mycket tekniskt avancerad och bra lösning när du verkligen behöver tillhandahålla RTO på några sekunder eller minuter. Men om det inte finns någon sådan uppgift, och RTO i timmar är OK för affärer, så är det ingen idé att skjuta sparvar från en kanon. Den vanliga replikeringen av arbetare och bönder är tillräcklig, eftersom ett metrokluster kommer att orsaka extra kostnader och komplicering av IT-infrastrukturen.
Metrokluster planering
Det här avsnittet gör inte anspråk på att vara en heltäckande guide till design av metrokluster, utan visar bara de huvudinriktningar som bör utarbetas om du bestämmer dig för att bygga ett sådant system. Se därför till att involvera tillverkaren av lagringssystem (det vill säga oss) och andra relaterade system för konsultationer när du faktiskt implementerar ett metrokluster.
Spelplatser
Som nämnts ovan kräver ett metrokluster minst tre platser. Två datacenter där lagringssystem och relaterade system kommer att fungera, samt en tredje plats där skiljemannen kommer att arbeta.
Det rekommenderade avståndet mellan datacenter är inte mer än 40 kilometer. Ett större avstånd kommer med stor sannolikhet att orsaka ytterligare förseningar, vilket i fallet med ett metrokluster är extremt oönskat. Låt oss påminna dig om att förseningar bör vara upp till 5 millisekunder, även om det är tillrådligt att hålla dem inom 2.
Det rekommenderas att kontrollera förseningar även under planeringen. Varje mer eller mindre mogen leverantör som tillhandahåller optisk fiber mellan datacenter kan organisera en kvalitetskontroll ganska snabbt.
När det gäller förseningar innan skiljedomaren (det vill säga mellan den tredje platsen och de två första), är den rekommenderade fördröjningströskeln upp till 200 millisekunder, det vill säga en vanlig företags VPN-anslutning över Internet är lämplig.
Byte och nätverk
Till skillnad från replikeringsschemat, där det räcker att ansluta lagringssystem från olika platser, kräver metroklusterschemat att värdar kopplas ihop med båda lagringssystemen på olika platser. För att göra det tydligare vad skillnaden är, visas båda scheman nedan.
Som framgår av diagrammet tittar våra värdar för plats 1 på både lagringssystem 1 och lagringssystem 2. Tvärtom, värdar för plats 2 tittar på både lagringssystem 2 och lagringssystem 1. Det vill säga att varje värd ser båda lagringssystemen. Detta är en förutsättning för driften av metroklustret.
Naturligtvis finns det inget behov av att ansluta varje värd med en optisk sladd till ett annat datacenter, inga portar eller sladdar räcker. Alla dessa anslutningar måste göras via Ethernet 10G+ eller FibreChannel 8G+ switchar (FC är endast för att ansluta värdar och lagringssystem för IO, replikeringskanalen är för närvarande endast tillgänglig via IP (Ethernet 10G+).
Nu några ord om nätverkstopologin. En viktig punkt är den korrekta konfigurationen av subnät. Det är nödvändigt att omedelbart definiera flera undernät för följande typer av trafik:
- Replikeringsundernätet över vilket data kommer att synkroniseras mellan lagringssystem. Det kan finnas flera av dem, i det här fallet spelar det ingen roll, allt beror på den nuvarande (redan implementerade) nätverkstopologin. Om det finns två av dem måste uppenbarligen routing konfigureras mellan dem;
- Lagringsundernät genom vilka värdar kommer åt lagringsresurser (om det är iSCSI). Det bör finnas ett sådant subnät i varje datacenter;
- Styr subnät, det vill säga tre routbara subnät på tre platser från vilka lagringssystem hanteras, och medlaren finns också där.
Vi överväger inte subnät för att komma åt värdresurser här, eftersom de är mycket beroende av uppgifterna.
Att separera olika trafik i olika subnät är extremt viktigt (det är särskilt viktigt att separera repliken från I/O), för om du blandar all trafik till ett "tjockt" subnät kommer denna trafik att vara omöjlig att hantera, och i förhållandena för två datacenter kan detta fortfarande orsaka olika alternativ för nätverkskollisioner. Vi kommer inte att fördjupa oss i denna fråga inom ramen för denna artikel, eftersom du kan läsa om hur du planerar ett nätverk som sträcker sig mellan datacenter på resurserna hos tillverkare av nätverksutrustning, där detta beskrivs i detalj.
Arbiter konfiguration
Medlaren måste ge tillgång till alla hanteringsgränssnitt i lagringssystemet via ICMP- och SSH-protokollen. Du bör också tänka på felsäkerheten hos domaren. Det finns en nyans här.
Arbiter failover är mycket önskvärt, men inte nödvändigt. Vad händer om domaren kraschar vid fel tidpunkt?
- Funktionen av metrokluster i normalt läge kommer inte att ändras, eftersom arbtir har absolut ingen effekt på driften av metroklustret i normalt läge (dess uppgift är att växla belastningen mellan datacenter i tid)
- Dessutom, om skiljedomaren av en eller annan anledning faller och "sover igenom" en olycka i datacentret, kommer ingen växling att ske, eftersom det inte kommer att finnas någon som ger de nödvändiga växlingskommandona och organiserar ett kvorum. I det här fallet kommer metroklustret att förvandlas till ett vanligt schema med replikering, som måste bytas manuellt under en katastrof, vilket kommer att påverka RTO.
Vad följer av detta? Om du verkligen behöver säkerställa en minsta RTO måste du se till att domaren är feltolerant. Det finns två alternativ för detta:
- Starta en virtuell maskin med en arbiter på en feltolerant hypervisor, lyckligtvis stöder alla vuxna hypervisorer feltolerans;
- Om du på den tredje platsen (på ett vanligt kontor) är för lat för att installera ett normalt kluster och det inte finns något existerande hypervozor-kluster, så har vi tillhandahållit en hårdvaruversion av arbiter, som är gjord i en 2U-låda i vilken två vanliga x-86-servrar fungerar och som kan överleva ett lokalt fel.
Vi rekommenderar starkt att du säkerställer feltoleransen för arbitern, trots att metroklustret inte behöver det i normalt läge. Men som både teori och praktik visar, om du bygger en verkligt pålitlig katastrofsäker infrastruktur är det bättre att spela det säkert. Det är bättre att skydda dig själv och ditt företag från "edelaktighetens lag", det vill säga från misslyckandet hos både skiljemannen och en av platserna där lagringssystemet finns.
Lösningsarkitektur
Med tanke på kraven ovan får vi följande generella lösningsarkitektur.
LUN:er bör vara jämnt fördelade över två platser för att undvika allvarlig överbelastning. Samtidigt, när du dimensionerar i båda datacentren, bör du inte bara inkludera dubbel volym (vilket är nödvändigt för att lagra data samtidigt på två lagringssystem), utan också dubbel prestanda i IOPS och MB/s för att förhindra applikationsförsämring i händelse av ett fel i ett av datacentren ov.
Separat noterar vi att med rätt tillvägagångssätt för dimensionering (det vill säga förutsatt att vi har tillhandahållit de lämpliga övre gränserna för IOPS och MB/s, såväl som nödvändiga CPU- och RAM-resurser), om ett av lagringssystemen i metro kluster misslyckas, kommer det inte att bli en allvarlig nedgång i prestanda under förhållanden tillfälligt arbete på ett lagringssystem.
Detta förklaras av det faktum att när två platser är i drift samtidigt "äter" synkron replikering hälften av skrivprestandan, eftersom varje transaktion måste skrivas till två lagringssystem (liknande RAID-1/10). Så om ett av lagringssystemen misslyckas försvinner replikeringens inflytande tillfälligt (tills det misslyckade lagringssystemet återställs) och vi får en dubbel ökning av skrivprestanda. Efter att LUN:erna för det misslyckade lagringssystemet har startat om på det fungerande lagringssystemet, försvinner denna dubbla ökning på grund av det faktum att belastning visas från LUN:erna för det andra lagringssystemet, och vi återgår till samma prestandanivå som vi hade innan "falla", men bara inom ramen för en webbplats.
Med hjälp av kompetent dimensionering kan du säkerställa förhållanden under vilka användare inte alls kommer att känna felet i ett helt lagringssystem. Men vi upprepar ännu en gång, detta kräver mycket noggrann dimensionering, för vilket du förresten kan kontakta oss gratis :-).
Att skapa ett metrokluster
Att sätta upp ett metrokluster är mycket likt att ställa in vanlig replikering, som vi beskrev i . Låt oss därför bara fokusera på skillnaderna. Vi satte upp en bänk i laboratoriet utifrån arkitekturen ovan, bara i en minimal version: två lagringssystem anslutna via 10G Ethernet, två 10G-switchar och en värd som tittar igenom switcharna på båda lagringssystemen med 10G-portar. Medlaren körs på en virtuell maskin.
När du konfigurerar virtuella IP:er (VIP) för en replik, bör du välja VIP-typen - för metrokluster.
Vi skapade två replikeringslänkar för två LUN:er och distribuerade dem över två lagringssystem: LUN TEST Primary på lagringssystem 1 (METRO-länk), LUN TEST2 Primary för lagringssystem 2 (METRO2-länk).
För dem konfigurerade vi två identiska mål (i vårt fall iSCSI, men FC stöds också, inställningslogiken är densamma).
Lagringssystem 1:
Lagringssystem 2:
För replikeringsanslutningar gjordes mappningar på varje lagringssystem.
Lagringssystem 1:
Lagringssystem 2:
Vi satte upp multipath och presenterade det för värden.
Inrätta en skiljedomare
Du behöver inte göra något speciellt med själva arbitern; du behöver bara aktivera den på den tredje platsen, ge den en IP och konfigurera åtkomst till den via ICMP och SSH. Själva installationen utförs från själva lagringssystemen. I det här fallet räcker det att konfigurera arbitern en gång på någon av lagringskontrollerna i metroklustret; dessa inställningar kommer att distribueras till alla kontroller automatiskt.
I avsnittet Fjärrreplikering>> Metrocluster (på valfri kontroller)>> knappen "Konfigurera".
Vi anger IP-adressen för domaren, såväl som kontrollgränssnitten för två fjärrlagringskontroller.
Efter detta måste du aktivera alla tjänster (knappen "Starta om allt"). Om de konfigureras om i framtiden måste tjänsterna startas om för att inställningarna ska träda i kraft.
Vi kontrollerar att alla tjänster är igång.
Detta slutför konfigurationen av metrokluster.
Krocktest
Krocktestet i vårt fall kommer att vara ganska enkelt och snabbt, eftersom replikeringsfunktionaliteten (växling, konsistens etc.) diskuterades i . För att testa metroklustrets tillförlitlighet är det därför tillräckligt för oss att kontrollera automatiseringen av feldetektering, omkoppling och frånvaron av inspelningsförluster (I/O-stopp).
För att göra detta emulerar vi ett fullständigt fel i ett av lagringssystemen genom att fysiskt stänga av båda dess kontroller, efter att först ha börjat kopiera en stor fil till LUN, som måste aktiveras på det andra lagringssystemet.
Inaktivera ett lagringssystem. På det andra lagringssystemet ser vi varningar och meddelanden i loggarna om att anslutningen till det angränsande systemet har tappats. Om aviseringar via SMTP- eller SNMP-övervakning är konfigurerade kommer administratören att få motsvarande meddelanden.
Exakt 10 sekunder senare (synligt i båda skärmdumparna) blev METRO-replikeringsanslutningen (den som var Primär på det misslyckade lagringssystemet) automatiskt Primär på det fungerande lagringssystemet. Med hjälp av den befintliga kartläggningen förblev LUN TEST tillgängligt för värden, inspelningen sjönk lite (inom de utlovade 10 procenten), men avbröts inte.
Testet slutfördes framgångsrikt.
Sammanfattning
Den nuvarande implementeringen av metroklustret i AERODISK Engine N-seriens lagringssystem tillåter fullt ut att lösa problem där det är nödvändigt att eliminera eller minimera driftstopp för IT-tjänster och säkerställa deras drift 24/7/365 med minimala arbetskostnader.
Vi kan naturligtvis säga att allt detta är teori, idealiska laboratorieförhållanden och så vidare... MEN vi har ett antal genomförda projekt där vi har implementerat katastrofresiliensfunktionalitet, och systemen fungerar perfekt. En av våra ganska välkända kunder, som använder bara två lagringssystem i en katastrofsäker konfiguration, har redan gått med på att publicera information om projektet, så i nästa del kommer vi att prata om stridsimplementeringen.
Tack, vi ser fram emot en produktiv diskussion.
Källa: will.com