Afhankelijk van hoe krachtig de apparatuur die we hebben en de benodigde middelen voor onze systemen, zullen we een gemiddelde verhouding van virtuele machines per server hebben.
Neem bijvoorbeeld het geplande onderhoud van een server in het Computercentrum. Als dit enkele jaren geleden geen onderdeel was van een cluster, zou het systeem in de apparatuur offline worden gehaald, waardoor ook de gebruikers zouden worden getroffen en / of het personeel dat betrokken was bij het onderhoud in kortere tijdsvensters moest werken (om niet te zeggen ongemakkelijk).
In het geval van een gevirtualiseerde omgeving kunnen virtuele machines eenvoudig worden "verplaatst of gemigreerd" naar een ander lid van een cluster en de apparatuur kan worden uitgeschakeld om eraan te werken. Probleem opgelost.
Laten we beginnen met situaties te zien waarin het gebrek aan service niet is geprogrammeerd.
Bewaking van virtuele machines en toepassingen
Elke keer dat we een virtuele machine maken, wordt aanbevolen om een compendium van toepassingen en stuurprogramma's te installeren die het gedrag van de virtuele hardware in zijn geheel optimaliseren (beschikbaar voor Windows, Mac OS, Linux en andere besturingssystemen). Deze tools, VMTools genaamd, omvatten onder meer de mogelijkheid voor de host om de virtuele machine te monitoren (via hartslagen, zoals in clusters). Als het niet binnen een bepaalde periode reageert, wordt uw besturingssysteem opnieuw gestart.
Een soortgelijk geval doet zich voor met applicatiebewaking, maar eerst moet u de juiste SDK verkrijgen (of een applicatie gebruiken die VMware Application Monitoring ondersteunt).
Maar … wat gebeurt er als de fout hardwarematig is?
Het hierboven genoemde cluster is de eerste laag van de oplossing.
Gedeelde opslagWaar alle leden van het cluster toegang hebben tot virtuele machines.
NetwerkteamingGeconfronteerd met het falen van één bord, blijven de overige het verkeer beheren.
Meerdere paden (multipathing)Voor opslag zullen ze niet alleen de toegang optimaliseren, maar ook redundantie bieden.
In het algemeen verminderen deze drie technologieën de tijd dat onze informatie ontoegankelijk is. Nu, afhankelijk van de licenties die we hebben, kunnen we ook twee zeer interessante functies hebben: High Availability (HA) en Fault Tolerance (FT).
In beide gevallen hebben we een cluster met gedeelde opslag nodig. Zonder de noodzaak om extra software te installeren, kan HA zo worden ingeschakeld en geconfigureerd dat als een server of virtuele machine in het cluster uitvalt, deze automatisch wordt gestart op een ander lid van het cluster. Het is de moeite waard om te verduidelijken dat HA niet bedoeld is voor missiekritieke VM's (virtuele machines). Dus de geschatte tijd zonder service zal zijn: "Het besturingssysteem starten + de services starten".
Aantal hostfouten dat door het cluster wordt ondersteund
We hebben X aantal virtuele machines verdeeld over Y servers in een cluster.
Hoeveel hosts kunnen falen zonder de beschikbaarheid en prestaties van onze virtuele omgeving te beïnvloeden?
HA kan worden geconfigureerd om een specifiek aantal serverstoringen te ondersteunen, zodat er voldoende middelen overblijven voor herstel.
HA verdeelt de beschikbare bronnen van een cluster, rekening houdend met CPU en RAM die zijn geconfigureerd en verbruikt door onze virtuele machines op een zeer conservatieve manier. Het neemt de grootste geconfigureerde CPU-reservering van elke VM op elke host in het cluster en vervolgens de grootste geheugenreservering en het overschot. Als er geen reservering is geconfigureerd, duurt het minimaal 32 Mhz per VM voor CPU en 0 Mb RAM + het eigen risico.
Met deze getallen gaat het ervan uit dat elke gebruikte virtuele machine die CPU en geheugen zal verbruiken, waarna het een waarde genereert die slotgrootte wordt genoemd. Met deze waarde wordt bepaald hoeveel slots er beschikbaar/gebruikt zijn door elke host.
Het probleem ontstaat wanneer we bijvoorbeeld een enkele machine hebben met een grote CPU- en geheugenreserve. Door geconfigureerde reserveringen aan te nemen, is het zeer waarschijnlijk dat de rest van onze virtuele machines die bronnen niet echt nodig hebben, wat resulteert in minder slots voor ons cluster.
Percentage clusterbronnen als capaciteit voor mislukkingen
In tegenstelling tot de vorige optie, werkt deze heel goed wanneer je VM's hebt met zeer variabele CPU- en geheugenconfiguraties.
Het is mogelijk om procentuele waarden van CPU en geheugen afzonderlijk te configureren, waardoor het nog flexibeler is en dus resources bespaart. Dit is over het algemeen de voorkeursmethode voor het configureren van HA.
Hosts voor failover
Dit is de typische standby-clusterconfiguratie. Deze optie wordt voornamelijk gegeven omdat sommige organisaties beleid hanteren dat aangeeft dat er servers stand-by moeten zijn in het geval van een calamiteit. Aangezien VMware goed fouttolerantiebeheer uitvoert, zou dit misschien de optie zijn als er voldoende bronnen zijn … maar zeker niet de beste.
vMotie: Live migraties
Met livemigratie kunt u werkende virtuele machines van de ene fysieke server naar de andere verplaatsen terwijl u uw netwerkverbinding en identiteit behoudt. Actief geheugen (lopende processen) wordt overgedragen via het hogesnelheidsnetwerk. Het hele proces duurt minder dan 5 seconden op een gigabit-netwerk.
Het is mogelijk om de VM, de bestanden die het gebruikt of beide te verplaatsen, en de procedure kan worden uitgevoerd met de machine aan of uit. In het laatste geval noemen we het "koude migratie" en als de machine draait, noemen we het vMotion.
Gebruik en voordelen van vMotion
- VM reorganisatie, waardoor de middelen worden geoptimaliseerd. Verwijder ze van servers die gevoelig zijn voor storingen of verzadigd zijn.
- Automatische optimalisatie van beschikbare resources (Ik werk samen met Dynamic Resource Scheduler of DRS).
- Doen onderhoud van de onderliggende infrastructuur geen onderhoudsplanning of bedrijfsonderbreking nodig.
Elk onderdeel van de VM-status wordt tijdens de migratie anders afgehandeld. De algemene configuratie is de eenvoudigste, deze beweegt niet maar wordt opnieuw gemaakt op de doelcomputer.
Aangezien de schijf niet in zo'n korte tijd opnieuw kan worden gemaakt, is gedeelde opslag noodzakelijk. De huidige status van het geheugen wordt geleidelijk gekopieerd naar de doelhost. Aan het einde van de kopie worden de bestaande verschillen die tijdens de migratie zijn ontstaan vergeleken, de status van de bron-VM wordt bevroren en het besturingssysteem wordt geactiveerd op de doel-VM .
Omdat in sommige gevallen de optie om de machine opnieuw op te starten niet ideaal is, hebben we voor mission critical de Fouttolerantie. Wat in deze gevallen gewenst is, stopt op geen enkel moment met werken, zelfs als de host faalt. De enige manier waarop dit mogelijk is, is als de VM op twee plaatsen tegelijkertijd draait. Het is geconfigureerd op het niveau van de virtuele machine en genereert een exacte kopie van de VM, zodat deze te allen tijde 100% gerepliceerd wordt op een andere server, dus in het geval van een hardwarestoring, blijft zijn twin gewoon functioneren zonder verlies van informatie. Interessant, toch?
Als het alleen om resources ging, zouden we FT inschakelen in alle virtuele machines in ons datacenter, maar in eerdere versies van vSphere kwamen we enkele beperkingen tegen, de belangrijkste: het was niet mogelijk om FT in te schakelen op machines die meer dan één virtuele machine gebruikten. verwerker. Gelukkig ondersteunt het in de nieuwste versie van het product tot 4 virtuele processors tegelijk per beschermde machine, maar er moet rekening worden gehouden met licenties:
Het aantal vCPU's dat wordt ondersteund door een FT-compatibele VM wordt beperkt door het licentieniveau dat voor vSphere is gekocht.
Fouttolerantie wordt als volgt ondersteund:
- vSphere Standard en Enterprise. Staat maximaal 2 vCPU's toe.
- vSphere Enterprise Plus. Staat maximaal 4 vCPU's toe.
Dat is niet de enige eis van het systeem.
OpslagVm's moeten gedeelde opslag hebben. Het is niet mogelijk om fysieke RDM (Raw Devide Mapping) te gebruiken.
NettoHet is noodzakelijk om ten minste twee virtuele kaarten (vmnics) te hebben, één voor vMotion en de andere (10 gbps) voor FT Logging. Het is een nieuwe vereiste van versie 6 (voorheen waren platen van 1 gbps nodig)
VerwerkerProcessoren en besturingssystemen moeten compatibel zijn met FT (en met elkaar).
Beperkingen
- Het is niet mogelijk om snapshots te maken van de VM's die worden beschermd met FT en ze moeten worden verwijderd voordat deze functie wordt ingeschakeld.
- Virtuele schijven (VMDK) groter dan 2 Tb.
- Er is een lijst met specifieke apparaten en functies in de VMware-documentatie.
En er is ook een limiet op het aantal VM's per server: maximaal 4 beveiligde machines per host of 8 beveiligde vCPU's (welke limiet het eerst komt). Deze maxima zijn inclusief de primaire en secundaire machine (en vCPU's)
Verschillen tussen FT legacy (vorige) en huidige
IPv6
Legacy FT = Niet ondersteund door netwerkkaarten die zijn geconfigureerd voor FT-registratie FT = Ondersteund
VStorage API's - Back-up met gegevensbescherming
Legacy FT = Niet ondersteund FT = Ondersteund
Virtuele schijf
Legacy FT = EZT (Eager Zeroed Thick) FT = Alle typen, inclusief dik en dun
Vmdk-redundantie (virtuele schijf)
Legacy FT = Single copy FT = De primaire en secundaire machines behouden onafhankelijke kopieën, hierdoor kunnen ze in verschillende datastores worden opgeslagen en wordt de redundantie verhoogd
Bandbreedte netwerkplaat
Legacy FT = Dedicated 1-Gb NIC aanbevolen FT = Dedicated 10-Gb NIC aanbevolen
Compatibiliteit met CPU en host
Legacy FT = vereist hetzelfde CPU-model en dezelfde familie. Vrijwel identieke vSphere-versies FT = CPU's moeten compatibel zijn met vSphere vMotion of EVC. Vsphere-versie moet compatibel zijn met vSphere vMotion
Activeer / Deactiveer FT terwijl de machine draait
Legacy FT = Niet altijd ondersteund FT = Ondersteund
Onthoud dat FT beschermt tegen storingen in serverhardware, niet tegen storingen van besturingssystemen of toepassingen.
vCenter Server Watchdog het is een ingebouwde functionaliteit van versie 6.x. Het controleert periodiek de status van de services waaruit vCenter bestaat, het zal indien nodig de beheerprocessen of de VM opnieuw opstarten.
