Hé Habr!
Na de nieuwjaarsvakantie hebben we een rampbestendige cloud opnieuw gelanceerd op basis van twee sites. Vandaag vertellen we je hoe het werkt en laten we zien wat er gebeurt met virtuele clientmachines wanneer individuele elementen van het cluster falen en de hele site crasht (spoiler – alles is in orde met hen).
Rampbestendig cloudopslagsysteem op de OST-site.
Wat is er binnenin
Onder de motorkap beschikt het cluster over Cisco UCS-servers met een VMware ESXi-hypervisor, twee INFINIDAT InfiniBox F2240-opslagsystemen, Cisco Nexus-netwerkapparatuur en Brocade SAN-switches. Het cluster is verdeeld in twee locaties: OST en NORD, d.w.z. elk datacenter heeft een identieke set apparatuur. Eigenlijk is dit wat het rampbestendig maakt.
Binnen één site zijn ook de belangrijkste elementen gedupliceerd (hosts, SAN-switches, netwerken).
De twee locaties zijn verbonden via speciale glasvezelroutes, eveneens gereserveerd.
Een paar woorden over opslagsystemen. We bouwden de eerste versie van een rampbestendige cloud op NetApp. Hier kozen we voor INFINIDAT, en dit is waarom:
- Actief-actieve replicatieoptie. Hierdoor kan de virtuele machine operationeel blijven, zelfs als een van de opslagsystemen volledig uitvalt. Over replicatie vertel ik je later meer.
- Drie schijfcontrollers om de systeemfouttolerantie te vergroten. Meestal zijn het er twee.
- Klaar oplossing. We hebben een voorgemonteerd rack ontvangen dat alleen nog maar op het netwerk hoeft te worden aangesloten en geconfigureerd.
- Attente technische ondersteuning. INFINIDAT-technici analyseren voortdurend logboeken en gebeurtenissen van het opslagsysteem, installeren nieuwe firmwareversies en helpen bij de configuratie.
Hier enkele foto's van het uitpakken:
Hoe het werkt
De cloud is van zichzelf al fouttolerant. Het beschermt de client tegen afzonderlijke hardware- en softwarefouten. Rampbestendig helpt beschermen tegen enorme storingen binnen één locatie: bijvoorbeeld het falen van een opslagsysteem (of een SDS-cluster, wat vrij vaak voorkomt 🙂), enorme fouten in een opslagnetwerk, enz. Nou ja, en het allerbelangrijkste: zo'n cloud bespaart wanneer een hele site ontoegankelijk wordt vanwege een brand, stroomstoring, overname van een raider of een landing van buitenaardse wezens.
In al deze gevallen blijven de virtuele machines van de client werken, en dit is de reden.
Het clusterontwerp is zo ontworpen dat elke ESXi-host met virtuele clientmachines toegang heeft tot elk van de twee opslagsystemen. Als het opslagsysteem op de OST-site uitvalt, blijven de virtuele machines werken: de hosts waarop ze draaien, hebben toegang tot het opslagsysteem op NORD voor gegevens.
Zo ziet het aansluitschema in een cluster eruit.
Dit is mogelijk vanwege het feit dat er een Inter-Switch Link is geconfigureerd tussen de SAN-fabrics van de twee locaties: de Fabric A OST SAN-switch is verbonden met de Fabric A NORD SAN-switch, en op dezelfde manier voor de Fabric B SAN-switches.
Om al deze fijne kneepjes van SAN-fabrieken zinvol te maken, wordt Active-Active-replicatie geconfigureerd tussen de twee opslagsystemen: informatie wordt vrijwel gelijktijdig naar de lokale en externe opslagsystemen geschreven, RPO = 0. Het blijkt dat de originele gegevens op het ene opslagsysteem zijn opgeslagen en de replica ervan op het andere. Gegevens worden gerepliceerd op het niveau van opslagvolumes en de VM-gegevens (de schijven, het configuratiebestand, het wisselbestand, enz.) worden daarop opgeslagen.
De ESXi-host ziet het primaire volume en de replica ervan als één schijfapparaat (opslagapparaat). Er zijn 24 paden van de ESXi-host naar elk schijfapparaat:
Twaalf paden verbinden het met het lokale opslagsysteem (optimale paden), en de overige twaalf met het externe opslagsysteem (niet-optimale paden). In een normale situatie heeft ESXi toegang tot gegevens op het lokale opslagsysteem via ‘optimale’ paden. Wanneer dit opslagsysteem faalt, verliest ESXi de optimale paden en schakelt over naar “niet-optimale” paden. Zo ziet het eruit op het diagram.
Schema van een rampbestendig cluster.
Alle clientnetwerken zijn via een gemeenschappelijk netwerknetwerk met beide locaties verbonden. Elke site draait een Provider Edge (PE), waarop de netwerken van de klant worden beëindigd. PE's zijn verenigd in een gemeenschappelijk cluster. Als een PE op één site faalt, wordt al het verkeer omgeleid naar de tweede site. Hierdoor blijven virtuele machines van de site zonder PE via het netwerk toegankelijk voor de klant.
Laten we nu eens kijken wat er zal gebeuren met virtuele clientmachines tijdens verschillende storingen. Laten we beginnen met de lichtste opties en eindigen met de meest ernstige: het falen van de hele site. In de voorbeelden zal het hoofdplatform OST zijn en het back-upplatform, met gegevensreplica's, NORD.
Wat gebeurt er met de virtuele clientmachine als...
Replicatiekoppeling mislukt. De replicatie tussen de opslagsystemen van de twee locaties stopt.
ESXi werkt alleen met lokale schijfapparaten (via optimale paden).
Virtuele machines blijven werken.
De ISL (Inter-Switch Link) breekt. De zaak is onwaarschijnlijk. Tenzij een of andere gekke graafmachine meerdere optische routes tegelijk uitgraaft, die op onafhankelijke routes lopen en via verschillende ingangen naar de locaties worden gebracht. Maar in ieder geval. In dit geval verliezen ESXi-hosts de helft van de paden en hebben ze alleen toegang tot hun lokale opslagsystemen. Replica's worden verzameld, maar hosts hebben er geen toegang toe.
Virtuele machines werken normaal.
Op één van de locaties faalt de SAN-switch. ESXi-hosts verliezen een deel van de paden naar het opslagsysteem. In dit geval werken de hosts op de locatie waar de overstap is mislukt alleen via een van hun HBA's.
De virtuele machines blijven normaal werken.
Alle SAN-switches op een van de locaties vallen uit. Laten we zeggen dat zo'n ramp plaatsvond op de OST-site. In dit geval verliezen ESXi-hosts op deze site alle paden naar hun schijfapparaten. Het standaard VMware vSphere HA-mechanisme komt in actie: het zal alle virtuele machines van de OST-site in NORD in maximaal 140 seconden opnieuw opstarten.
Virtuele machines die op NORD-sitehosts draaien, werken normaal.
De ESXi-host faalt op één site. Hier werkt het vSphere HA-mechanisme weer: virtuele machines van de defecte host worden opnieuw opgestart op andere hosts - op dezelfde of externe site. De herstarttijd van de virtuele machine bedraagt maximaal 1 minuut.
Als alle ESXi-hosts op de OST-site uitvallen, zijn er geen opties: de VM's worden opnieuw opgestart op een andere. De herstarttijd is hetzelfde.
Op één locatie faalt het opslagsysteem. Laten we zeggen dat het opslagsysteem faalt op de OST-site. Vervolgens schakelen de ESXi-hosts van de OST-site over op het werken met opslagreplica's in NORD. Nadat het defecte opslagsysteem weer in gebruik is genomen, zal geforceerde replicatie plaatsvinden en zullen de ESXi OST-hosts opnieuw toegang krijgen tot het lokale opslagsysteem.
Virtuele machines hebben al die tijd normaal gewerkt.
Eén van de sites faalt. In dit geval worden alle virtuele machines opnieuw opgestart op de back-upsite via het vSphere HA-mechanisme. De herstarttijd van de VM is 140 seconden. In dit geval worden alle netwerkinstellingen van de virtuele machine opgeslagen en blijft deze via het netwerk toegankelijk voor de client.
Om ervoor te zorgen dat het herstarten van machines op de back-upsite soepel verloopt, is elke site slechts voor de helft gevuld. De tweede helft is een reserve voor het geval alle virtuele machines van de tweede, beschadigde locatie verhuizen.
Een rampbestendige cloud op basis van twee datacenters beschermt tegen dergelijke storingen.
Dit plezier is niet goedkoop, omdat er naast de hoofdbronnen ook een reserve nodig is op de tweede site. Daarom worden bedrijfskritische diensten in een dergelijke cloud geplaatst, waarvan de langdurige downtime grote financiële en reputatieschade veroorzaakt, of als het informatiesysteem onderworpen is aan vereisten inzake rampenbestendigheid van toezichthouders of interne bedrijfsregelgeving.
Bronnen:
Bron: www.habr.com