Hej Habr!
Efter nyårshelgerna återlanserade vi ett katastrofsäkert moln baserat på två sajter. Idag ska vi berätta hur det fungerar och visa vad som händer med virtuella klientmaskiner när enskilda delar av klustret misslyckas och hela webbplatsen kraschar (spoiler – allt är bra med dem).
Katastrofbeständigt molnlagringssystem på OST-webbplatsen.
Vad är inuti
Under huven har klustret Cisco UCS-servrar med en VMware ESXi hypervisor, två INFINIDAT InfiniBox F2240 lagringssystem, Cisco Nexus nätverksutrustning, samt Brocade SAN-switchar. Klustret är uppdelat i två platser - OST och NORD, det vill säga varje datacenter har en identisk uppsättning utrustning. Det är faktiskt det som gör den katastrofbeständig.
Inom en plats dupliceras även huvudelementen (värdar, SAN-switchar, nätverk).
De två platserna är förbundna med dedikerade fiberoptiska vägar, även reserverade.
Några ord om lagringssystem. Vi byggde den första versionen av ett katastrofsäkert moln på NetApp. Här valde vi INFINIDAT, och här är anledningen:
- Aktiv-aktiv replikeringsalternativ. Det gör att den virtuella maskinen kan fortsätta att fungera även om ett av lagringssystemen helt misslyckas. Jag ska berätta mer om replikering senare.
- Tre diskkontroller för att öka systemets feltolerans. Vanligtvis finns det två.
- Färdig lösning. Vi fick ett förmonterat rack som bara behöver anslutas till nätverket och konfigureras.
- Uppmärksam teknisk support. INFINIDATs ingenjörer analyserar ständigt lagringssystemloggar och händelser, installerar nya firmwareversioner och hjälper till med konfigurationen.
Här är några bilder från uppackningen:
Hur fungerar det?
Molnet är redan feltolerant inom sig självt. Det skyddar klienten från enskilda hårdvaru- och mjukvarufel. Katastrofbeständig kommer att hjälpa till att skydda mot massiva fel inom en plats: till exempel fel i ett lagringssystem (eller ett SDS-kluster, vilket händer ganska ofta 🙂), massiva fel i ett lagringsnätverk, etc. Tja, och viktigast av allt: ett sådant moln räddar när en hel webbplats blir otillgänglig på grund av en brand, blackout, raider-övertagande eller utomjordingar.
I alla dessa fall fortsätter klientens virtuella datorer att fungera, och här är anledningen.
Klusterdesignen är utformad så att alla ESXi-värdar med virtuella klientdatorer kan komma åt vilket som helst av de två lagringssystemen. Om lagringssystemet på OST-platsen misslyckas, kommer de virtuella maskinerna att fortsätta att fungera: värdarna som de körs på kommer åt lagringssystemet på NORD för data.
Så här ser kopplingsschemat i ett kluster ut.
Detta är möjligt på grund av det faktum att en Inter-Switch Link är konfigurerad mellan SAN-strukturerna på de två platserna: Fabric A OST SAN-omkopplaren är ansluten till Fabric A NORD SAN-omkopplaren och på liknande sätt för Fabric B SAN-omkopplarna.
Tja, så att alla dessa krångligheter hos SAN-fabriker är meningsfulla, är Active-Active-replikering konfigurerad mellan de två lagringssystemen: information skrivs nästan samtidigt till de lokala och fjärrlagringssystemen, RPO = 0. Det visar sig att originaldata lagras på ett lagringssystem och dess replika lagras på det andra. Data replikeras på nivån för lagringsvolymer och VM-data (dess diskar, konfigurationsfil, växlingsfil, etc.) lagras på dem.
ESXi-värden ser den primära volymen och dess replik som en diskenhet (lagringsenhet). Det finns 24 vägar från ESXi-värden till varje diskenhet:
12 vägar ansluter den till det lokala lagringssystemet (optimala vägar), och de återstående 12 till fjärrlagringssystemet (icke-optimala vägar). I en normal situation kommer ESXi åt data på det lokala lagringssystemet med hjälp av "optimala" sökvägar. När detta lagringssystem misslyckas förlorar ESXi optimala vägar och växlar till "icke-optimala". Så här ser det ut på diagrammet.
Schema för ett katastrofsäkert kluster.
Alla klientnätverk är anslutna till båda platserna via en gemensam nätverksstruktur. Varje sida kör en Provider Edge (PE), där klientens nätverk avslutas. PE är förenade till ett gemensamt kluster. Om en PE misslyckas på en plats omdirigeras all trafik till den andra platsen. Tack vare detta förblir virtuella maskiner från webbplatsen utan PE tillgängliga över nätverket för klienten.
Låt oss nu se vad som kommer att hända med klientens virtuella maskiner under olika fel. Låt oss börja med de lättaste alternativen och avsluta med det allvarligaste - misslyckande på hela webbplatsen. I exemplen kommer huvudplattformen att vara OST, och backupplattformen, med datakopior, kommer att vara NORD.
Vad händer med klientens virtuella maskin om...
Replikeringslänken misslyckas. Replikeringen mellan lagringssystemen för de två platserna upphör.
ESXi fungerar endast med lokala diskenheter (via optimala sökvägar).
Virtuella maskiner fortsätter att fungera.
ISL (Inter-Switch Link) bryts. En osannolik händelse. Såvida inte någon galen grävmaskin gräver upp flera optiska rutter samtidigt, som går på oberoende rutter och förs till platserna genom olika ingångar. Men ändå. I det här fallet förlorar ESXi-värdar hälften av sökvägarna och kan bara komma åt sina lokala lagringssystem. Repliker samlas in, men värdar kommer inte att kunna komma åt dem.
Virtuella maskiner fungerar normalt.
SAN-växeln misslyckas på en av platserna. ESXi-värdar förlorar några av vägarna till lagringssystemet. I det här fallet kommer värdarna på platsen där bytet misslyckades endast att fungera via en av sina HBA:er.
De virtuella maskinerna fortsätter att fungera normalt.
Alla SAN-switchar på en av platserna misslyckas. Låt oss säga att en sådan katastrof inträffade på OST-webbplatsen. I det här fallet kommer ESXi-värdar på den här webbplatsen att förlora alla sökvägar till sina diskenheter. Standardmekanismen VMware vSphere HA kommer till spel: den kommer att starta om alla virtuella maskiner på OST-webbplatsen i NORD på maximalt 140 sekunder.
Virtuella maskiner som körs på NORDs webbplatsvärdar fungerar normalt.
ESXi-värden misslyckas på en plats. Här fungerar vSphere HA-mekanismen igen: virtuella maskiner från den misslyckade värden startas om på andra värdar - på samma eller fjärrplats. Den virtuella maskinens omstartstid är upp till 1 minut.
Om alla ESXi-värdar på OST-webbplatsen misslyckas, finns det inga alternativ: de virtuella datorerna startas om på en annan. Omstartstiden är densamma.
Lagringssystemet misslyckas på en plats. Låt oss säga att lagringssystemet misslyckas på OST-webbplatsen. Sedan går ESXi-värdarna på OST-webbplatsen över till att arbeta med lagringsrepliker i NORD. Efter att det misslyckade lagringssystemet återgår till tjänst kommer tvångsreplikering att ske och ESXi OST-värdarna kommer igen att börja få åtkomst till det lokala lagringssystemet.
Virtuella maskiner har fungerat normalt hela tiden.
En av webbplatserna misslyckas. I det här fallet kommer alla virtuella maskiner att startas om på säkerhetskopieringsplatsen via vSphere HA-mekanismen. VM omstartstid är 140 sekunder. I det här fallet kommer alla nätverksinställningar för den virtuella maskinen att sparas och den förblir tillgänglig för klienten över nätverket.
För att säkerställa att omstarten av maskiner på säkerhetskopieringsplatsen går smidigt är varje sida bara halvfull. Den andra halvan är en reserv ifall alla virtuella maskiner flyttar från den andra, skadade platsen.
Ett katastroftåligt moln baserat på två datacenter skyddar mot sådana fel.
Detta nöje är inte billigt, eftersom det, förutom huvudresurserna, behövs en reserv på den andra platsen. Därför placeras affärskritiska tjänster i ett sådant moln, vars långvariga driftstopp orsakar stora ekonomiska och anseendeförluster, eller om informationssystemet är föremål för katastrofbeständighetskrav från tillsynsmyndigheter eller interna företagsbestämmelser.
Källor:
Källa: will.com