Beroende på hur kraftfull utrustningen vi har och de nödvändiga resurserna för våra system kommer vi att ha ett genomsnittligt antal virtuella maskiner per server.
Ta till exempel det schemalagda underhållet av en server i Computer Center. För några år sedan om detta inte var en del av ett kluster skulle systemet i utrustningen tas offline, följaktligen skulle användarna också påverkas och / eller personalen som var involverad i underhållet fick arbeta i korta tidsfönster (för inte säga obekväm).
I en virtualiserad miljö kan virtuella maskiner helt enkelt "flyttas eller migreras" till en annan medlem i ett kluster och utrustningen kan stängas av för att arbeta med den. Problemet löst.
Låt oss börja se situationer där bristen på service inte är programmerad.
Virtuell maskin och applikationsövervakning
Varje gång vi skapar en virtuell maskin rekommenderas det att installera ett kompendium av applikationer och drivrutiner som optimerar den virtuella maskinvarans beteende i sin helhet (tillgängligt för Windows, Mac OS, Linux och annat operativsystem). Dessa verktyg, som kallas VMTools, inkluderar bland annat möjligheten för värden att övervaka den virtuella maskinen (genom hjärtslag, som i kluster). Om det inte svarar inom en viss period startar det om ditt operativsystem.
Ett liknande fall händer med applikationsövervakning, men först måste du skaffa rätt SDK (eller använda ett program som stöder VMware Application Monitoring).
Men … vad händer om felet är hårdvara?
Klustret som nämns ovan är det första lagret av lösningen.
Delad lagringDär alla medlemmar i klustret har tillgång till virtuella datorer.
Teaming i nätverkInför att en bräda misslyckas fortsätter de återstående att hantera trafiken.
Flera vägar (flervägar)För lagring optimerar de inte bara åtkomsten utan ger också redundans.
I stort sett mildrar dessa tre tekniker den tid då vår information är otillgänglig. Beroende på vilken licens vi har kan vi nu också ha två mycket intressanta funktioner: High Availability (HA) och Fault Tolerance (FT).
I båda fallen kräver vi ett kluster med delad lagring. Utan att behöva installera ytterligare programvara kan HA aktiveras och konfigureras på ett sådant sätt att om en server eller virtuell maskin misslyckas i klustret, startas den automatiskt på en annan medlem i klustret. Det är värt att förtydliga att HA inte är avsett för missionskritiska virtuella datorer (virtuella maskiner). Så den beräknade tiden utan service blir: "Starta operativsystemet + Starta tjänsterna".
Antal värdfel som stöds av klustret
Vi har X mängd virtuella maskiner distribuerade i Y -servrar i ett kluster.
Hur många värdar kan misslyckas utan att påverka tillgängligheten och prestandan för vår virtuella miljö?
HA kan konfigureras för att stödja ett visst antal serverfel, vilket säkerställer att det finns tillräckligt med resurser kvar i återställningen.
HA delar upp de tillgängliga resurserna i ett kluster med hänsyn till CPU och RAM som konfigureras och förbrukas av våra virtuella maskiner på ett mycket konservativt sätt. Den tar den största konfigurerade CPU -reservationen av någon virtuell dator på varje värd i klustret och sedan den största minnesreservationen och dess överskott. Om det inte finns någon reservation konfigurerad tar det minst 32 Mhz per virtuell dator för CPU och 0 Mb RAM + dess överskott.
Med dessa siffror antar det att varje virtuell maskin använder kommer att konsumera den CPU och minnet, då genererar det ett värde som kallas slotstorlek. Med detta värde bestäms hur många platser som är tillgängliga / används av varje värd.
Problemet uppstår när vi till exempel har en enda maskin med stor CPU och minnesreserv. Genom att ta konfigurerade reservationer är det mycket troligt att resten av våra virtuella maskiner inte verkligen behöver dessa resurser, vilket resulterar i färre platser för vårt kluster.
Procentandel av klusterresurser som kapacitet för misslyckanden
Till skillnad från det föregående alternativet fungerar det här mycket bra när du har virtuella datorer med mycket variabla CPU- och minneskonfigurationer.
Det är möjligt att konfigurera procentuella värden för CPU och minne separat, vilket är ännu mer flexibelt och därmed sparar resurser. Detta är i allmänhet den föredragna metoden för att konfigurera HA.
Värdar för failover
Detta är den typiska standby -klusterkonfigurationen. Detta alternativ ges huvudsakligen eftersom vissa organisationer upprätthåller policyer som anger att det måste finnas servrar i beredskap i händelse av katastrof. Eftersom VMware gör en bra feltoleranshantering kanske detta skulle vara alternativet när det finns gott om resurser … men definitivt inte det bästa.
vMotion: Levande migrationer
Live -migrering låter dig flytta fungerande virtuella maskiner från en fysisk server till en annan samtidigt som du behåller din nätverksanslutning och identitet. Aktivt minne (körprocesser) överförs över höghastighetsnätverket. Hela processen tar mindre än 5 sekunder på ett gigabit -nätverk.
Det är möjligt att flytta den virtuella datorn, filerna den använder eller båda, och proceduren kan göras med maskinen på eller av. I det senare fallet kallar vi det "kall migration" och om maskinen är igång kallar vi den vMotion.
Användningsområden och fördelar med vMotion
- VM -omorganisationoch därmed optimera resurser. Ta bort dem från servrar som är benägna att misslyckas eller mättas.
- Automatisk optimering av tillgängliga resurser (Jag arbetar tillsammans med Dynamic Resource Scheduler eller DRS).
- Do underhåll av den underliggande infrastrukturen inget behov av underhållsschemaläggning eller affärsavbrott.
Varje komponent i VM -hälsa hanteras annorlunda under migrering. Den allmänna konfigurationen är den enklaste, den rör sig inte utan återskapas på måldatorn.
Eftersom disken inte kan återskapas på så kort tid är det nödvändigt att ha delat lagringsutrymme. Det aktuella tillståndet i minnet kopieras gradvis till destinationsvärden. I slutet av kopian jämförs de befintliga skillnaderna som uppstod under migreringen, tillståndet för käll -VM fryses och operativsystemet aktiveras på destinations -VM .
Eftersom i vissa fall alternativet att starta om maskinen inte är idealiskt, för uppdragskritiska har vi Feltolerans. Det som önskas i dessa fall slutar inte fungera när som helst, även om dess värd misslyckas. Det enda sättet för detta är möjligt om den virtuella datorn kördes på två platser samtidigt. Den är konfigurerad på den virtuella datorn och genererar en exakt kopia av den virtuella datorn, så att den alltid kan replikeras 100% på en annan server, så i händelse av ett maskinvarufel kommer dess tvilling helt enkelt fortsätta att fungera utan förlust av information. Intressant, eller hur?
Om det bara handlade om resurser skulle vi aktivera FT i alla virtuella datorer i vårt datacenter, men i tidigare versioner av vSphere stötte vi på vissa begränsningar, det viktigaste: Det var inte möjligt att aktivera FT i maskiner som använde mer än en virtuell dator processor. Lyckligtvis stöder den i den senaste versionen av produkten upp till 4 virtuella processorer samtidigt per skyddad maskin, men licensiering måste övervägas:
Antalet vCPU: er som stöds av en FT-aktiverad virtuell dator begränsas av den licensnivå som köps för vSphere.
Feltolerans stöds enligt följande:
- vSphere Standard och Enterprise. Tillåter upp till 2 vCPU: er.
- vSphere Enterprise Plus. Tillåter upp till 4 vCPU: er.
Det är inte det enda kravet i systemet.
LagringVM måste ha delat lagringsutrymme. Det är inte möjligt att använda fysisk RDM (Raw Devide Mapping).
NettoDet är nödvändigt att ha minst två virtuella kort (vmnics), ett för vMotion och det andra (10 gbps) för FT Logging. Det är ett nytt krav på version 6 (tidigare behövdes 1 gbps -plattor)
ProcessorProcessorer och operativsystem måste vara kompatibla med FT (och med varandra).
Begränsningar
- Det är inte möjligt att ta ögonblicksbilder av de virtuella datorer som skyddas med FT och de måste raderas innan denna funktion aktiveras.
- Virtuella diskar (VMDK) större än 2 TB.
- Det finns en lista över specifika enheter och funktioner i VMware -dokumentationen.
Och det finns också en begränsning för antalet virtuella datorer per server: högst 4 skyddade datorer per värd eller 8 skyddade vCPU: er (vilken gräns som kommer först). Dessa maxvärden inkluderar den primära och sekundära maskinen (och vCPU: er)
Skillnader mellan FT -arv (tidigare) och nuvarande
IPv6
Äldre FT = Stöds inte av nätverkskort som är konfigurerade för FT -loggning FT = Stöds
VStorage API: er - Säkerhetskopiering med dataskydd
Äldre FT = Stöds inte FT = Stöds
Virtuell disk
Legacy FT = EZT (Eager Zeroed Thick) FT = Alla typer, inklusive tjockt och tunt
VMK -redundans (virtuell disk)
Äldre FT = Enstaka kopia FT = Primär- och sekundära maskiner upprätthåller oberoende kopior, detta gör att de kan lagras i olika datalagrar och öka redundansen
Bandbredd för nätverksplattor
Legacy FT = Dedikerad 1-Gb NIC rekommenderas FT = Dedikerad 10 Gb NIC rekommenderas
CPU- och värdkompatibilitet
Legacy FT = Kräver samma CPU -modell och familj. Nästan identiska vSphere -versioner FT = CPU: er måste vara kompatibla med vSphere vMotion eller EVC. VSphere -versionen måste vara kompatibel med vSphere vMotion
Aktivera / inaktivera FT när maskinen är igång
Äldre FT = Stöds inte alltid FT = Stöds
Kom ihåg att FT skyddar mot serverhårdvarufel, inte operativsystem eller programfel.
vCenter Server Watchdog det är en inbäddad funktionalitet av version 6.x. Det kontrollerar regelbundet statusen för de tjänster som utgör vCenter, det startar om administrationsprocesserna eller den virtuella datorn om det behövs.
