Hej, Habr!
Efter nyĂ„rshelgerna har vi startat om det katastrofsĂ€kra molnet baserat pĂ„ tvĂ„ platser. Idag berĂ€ttar vi hur det Ă€r uppbyggt och visar vad som hĂ€nder med kundernas virtuella maskiner vid fel pĂ„ enskilda klusterelement och ett helt omrĂ„des nedgĂ„ng (spoiler â de fungerar fortfarande bra).
Lagringssystemet för det katastrofsÀkra molnet pÄ OST-platsen.
Vad finns inuti
Under huven pĂ„ klustret finns servrar frĂ„n Cisco UCS med hypervisor VMware ESXi, tvĂ„ INFINIDAT InfiniBox F2240-lagringssystem, nĂ€tverksutrustning frĂ„n Cisco Nexus samt SAN-kontroller frĂ„n Brocade. Klustret Ă€r distribuerat över tvĂ„ platser â OST och NORD, vilket innebĂ€r att varje datacenter har en identisk uppsĂ€ttning av utrustning. Det Ă€r det som gör det katastrofsĂ€kert.
Inom en plats Àr ocksÄ huvudkomponenterna duplicerade (vÀrdmaskiner, SAN-switchar, nÀtverksutrustning).
De tvÄ platserna Àr kopplade med dedikerade fiberoptiska linjer, som ocksÄ Àr reservkopplade.
NÄgra ord om lagringssystemet. Den första versionen av det katastrofsÀkra molnet byggde vi pÄ NetApp. HÀr valde vi INFINIDAT, och hÀr Àr varför:
- Active-Active replikering. Den möjliggör att en virtuell maskin förblir verksam Àven vid fullstÀndig nedgÄng av ett av lagringssystemen. Jag kommer att berÀtta mer om replikeringen senare.
- Tre diskontrollerare för att öka systemets felresistens. Vanligtvis finns det tvÄ.
- FÀrdigt lösning. En redan monterad rack kom till oss, som bara behöver kopplas till nÀtverket och konfigureras.
- UppmÀrksam teknisk support. INFINIDAT:s ingenjörer analyserar stÀndigt loggar och hÀndelser frÄn lagringssystemet, installerar nya versioner av firmware och hjÀlper till med konfiguration.
HÀr Àr nÄgra bilder frÄn unpacking:
Hur det fungerar
Molnet Ă€r redan internt katastrofsĂ€kert. Det skyddar kunden mot enskilda hĂ„rdvaru- och programvarufel. Det katastrofsĂ€kra molnet hjĂ€lper till att skydda mot massfel i en enda plats: till exempel fel pĂ„ lagringssystemet (eller SDS-kluster, vilket ofta förekommer đ), massor av fel i lagringsnĂ€tverket och sĂ„ vidare. Och det viktigaste: ett sĂ„dant moln rĂ€ddar nĂ€r en hel plats blir otillgĂ€nglig pĂ„ grund av brand, strömavbrott, raiderövergrepp eller invasionsförsök av utomjordingar.
I alla dessa fall fortsÀtter kundernas virtuella maskiner att arbeta, och hÀr Àr varför.
Klustrets schema Àr uppbyggd sÄ att varje ESXi-vÀrd med klientvirtualiseringar kan nÄ antingen av de tvÄ lagringssystemen. Om lagringssystemet pÄ OST-platsen skulle krascha fortsÀtter de virtuella maskinerna att fungera: vÀrdarna, dÀr de körs, kommer att hÀmta data frÄn lagringssystemet pÄ NORD.
SÄ hÀr ser anslutningsschemat i klustret ut.
Detta Àr möjligt tack vare att det mellan SAN-fabrikerna pÄ de tvÄ platserna Àr instÀllt Uplink mellan switcharna: SAN-switch Fabric A OST Àr ansluten till SAN-switch Fabric A NORD, likadant för SAN-switcharna Fabric B.
För att alla dessa komplicerade nÀtverk av SAN-fabriker ska ha mening Àr en Active-Active-replikering instÀlld mellan de tvÄ lagringssystemen: information spelas in nÀstan samtidigt pÄ det lokala och det avlÀgsna lagringssystemet, RPO=0. Detta innebÀr att det pÄ ett lagringssystem finns en originaldata medan det pÄ det andra finns en replik. Data replikeras pÄ volymnivÄ av lagringssystemet, och pÄ dessa lagras data frÄn VM (dess diskar, konfigurationsfil, swap-fil osv.).
ESXi-vÀrden ser den primÀra volymen och dess replik som en enda lagringsenhet (Storage Device). FrÄn ESXi-vÀrden gÄr det 24 vÀgar till varje lagringsenhet:
12 vÀgar kopplar den till det lokala lagringssystemet (optimala vÀgar), och de övriga 12 till det avlÀgsna (inte optimala vÀgar). Under normala förhÄllanden hÀmtar ESXi data frÄn det lokala lagringssystemet med hjÀlp av de "optimala" vÀgarna. Om detta lagringssystem skulle krascha förlorar ESXi de optimala vÀgarna och byter till de "inte optimala". SÄ hÀr ser det ut i schemat.
Schema för katastrofsÀker kluster.
Alla klientnÀtverk Àr anslutna till bÄda platserna via en gemensam nÀtverksfabrik. PÄ varje plats finns en Provider Edge (PE), dÀr klienternas nÀtverk termineras. PE:erna Àr sammanlÀnkade i ett gemensamt kluster. Vid fel pÄ PE pÄ en plats omdirigeras all trafik till den andra platsen. Tack vare detta förblir de virtuella maskinerna pÄ den plats som inte har PE tillgÀngliga via nÀtverket för kunden.
LĂ„t oss nu titta pĂ„ vad som hĂ€nder med kundens virtuella maskiner vid olika fel. Vi börjar med de lĂ€ttaste alternativen och slutar med den mest allvarliga â ett fel pĂ„ hela platsen. I exemplen kommer den primĂ€ra platsen att vara OST, och den reservplats med datareplicationer kommer att vara NORD.
Vad hĂ€nder med kundens virtuella maskin omâŠ
ReplicationslÀnken faller. Replikationen mellan lagringssystemen pÄ de tvÄ platserna upphör.
ESXi kommer bara att fungera med lokala lagringsenheter (enligt optimala vÀgar).
De virtuella maskinerna fortsÀtter att fungera.
Det sker ett avbrott i ISL (Inter-Switch Link). Detta Àr osannolikt. Om en galen grÀvmaskin skulle grÀva upp flera optiska spÄr som löper oberoende rutter och Àr anslutna till plattformarna via olika ingÄngar. Men i sÄ fall. I detta fall förlorar ESXi-vÀrdar hÀlften av vÀgarna och kan bara nÄ sina lokala SAN. Replikerna samlas, men vÀrdarna kommer inte att kunna nÄ dem.
De virtuella maskinerna fungerar som vanligt.
SAN-switchen pÄ en av plattformarna har slutat fungera. ESXi-vÀrdar tappar en del av vÀgarna till SAN. I detta fall kommer vÀrdarna pÄ plattformen dÀr switchen har slutat fungera att arbeta endast genom sin egen HBA.
De virtuella maskinerna fortsÀtter att fungera som vanligt.
Alla SAN-switchar pÄ en av plattformarna har slutat fungera. Antag att en sÄdan katastrof intrÀffade pÄ plattformen OST. I sÄ fall kommer ESXi-vÀrdarna pÄ denna plattform att förlora alla vÀgar till sina lagringsenheter. Den standardmekanism som VMware vSphere HA har startas: den kommer att omstarta alla virtuella maskiner pÄ plattformen OST i NORD senast inom 140 sekunder.
De virtuella maskinerna som körs pÄ vÀrdarna pÄ plattformen NORD fungerar som vanligt.
En ESXi-vĂ€rd pĂ„ en plattform har slutat fungera. HĂ€r arbetar mekanismen vSphere HA igen: de virtuella maskinerna frĂ„n den kraschade vĂ€rden omstartas pĂ„ andra vĂ€rdar â pĂ„ samma eller en avlĂ€gsen plattform. Starttiden för den virtuella maskinen â upp till 1 minut.
Om alla ESXi-vÀrdar pÄ plattformen OST slutar fungera, finns det inget val: VM:erna omstartas pÄ en annan. Starttiden Àr densamma.
SAN har slutat fungera pÄ en plattform. Antag att SAN har slutat fungera pÄ plattformen OST. DÄ vÀxlar ESXi-vÀrdarna pÄ plattformen OST till att arbeta med repliker av SAN i NORD. Efter att den kraschade SAN har ÄterstÀllts kommer en tvingad replikering att ske, och ESXi-vÀrdarna OST kommer att börja nÄ den lokala SAN igen.
De virtuella maskinerna fungerar hela tiden som vanligt.
En av plattformarna har slutat fungera. I detta fall kommer alla virtuella maskiner att omstartas pÄ en reservplattform via mekanismen vSphere HA. Starttiden för VM Àr 140 sekunder. Under tiden kommer alla nÀtverksinstÀllningar för den virtuella maskinen att bevaras, och den förblir tillgÀnglig för kunden via nÀtverket.
För att omstarten av maskinerna pÄ den reservplatsen ska gÄ smidigt, Àr varje plats endast halvfull. Den andra halvan Àr en reserv ifall alla virtuella maskiner behöver flyttas frÄn den andra, drabbade platsen.
Det Àr detta som det katastrofresistenta molnet baserat pÄ tvÄ datacenter skyddar mot.
Detta nöje Àr inte billigt, eftersom man, utöver de grundlÀggande resurserna, behöver en reserv pÄ den andra platsen. DÀrför placeras affÀrskritiska tjÀnster i ett sÄdant moln, vars lÄnga driftstopp orsakar stora ekonomiska och reputationsförluster, eller om det finns krav pÄ katastrofresistens frÄn reglerande myndigheter eller interna regler inom företaget.
KĂ€llor:
KĂ€lla: habr.com
