Avhengig av hvor kraftig utstyret vi har og de nødvendige ressursene for systemene våre, vil vi ha et gjennomsnittlig forhold mellom virtuelle maskiner per server.
Ta for eksempel planlagt vedlikehold av en server i Computersenteret. For noen år siden, hvis dette ikke var en del av en klynge, ville systemet i utstyret bli frakoblet. Følgelig ville brukerne også bli påvirket og / eller personellet som var involvert i vedlikeholdet måtte arbeide i reduserte tidsvinduer (for ikke si ubehagelig).
I tilfelle av et virtualisert miljø kan virtuelle maskiner ganske enkelt "flyttes eller migreres" til et annet medlem av en klynge, og utstyret kan stenges ned for å jobbe med det. Problem løst.
La oss begynne å se situasjoner der mangel på service ikke er programmert.
Overvåking av virtuell maskin og applikasjoner
Hver gang vi lager en virtuell maskin, anbefales det å installere et kompendium av applikasjoner og drivere som optimaliserer den virtuelle maskinvarens oppførsel i sin helhet (tilgjengelig for Windows, Mac OS, Linux og annet operativsystem). Disse verktøyene, kalt VMTools, inkluderer blant annet muligheten for verten til å overvåke den virtuelle maskinen (gjennom hjerteslag, som i klynger). Hvis det ikke reagerer innen en viss periode, starter det operativsystemet på nytt.
En lignende sak skjer med applikasjonsovervåking, men først må du skaffe deg riktig SDK (eller bruke et program som støtter VMware Application Monitoring).
Men … hva skjer hvis feilen er maskinvare?
Klyngen nevnt ovenfor er det første laget av løsningen.
Delt lagringsplassDer alle medlemmer av klyngen har tilgang til virtuelle maskiner.
NettverksteamNår det ene brettet mislykkes, fortsetter de resterende å håndtere trafikken.
Flere stier (flerbaner)For lagring vil de ikke bare optimalisere tilgangen, men også gi redundans.
I grove trekk reduserer disse tre teknologiene tiden da informasjonen vår er utilgjengelig. Avhengig av lisensiering vi har, kan vi også ha to veldig interessante funksjoner: High Availability (HA) og Fault Tolerance (FT).
I begge tilfeller krever vi en klynge med delt lagring. Uten behov for å installere tilleggsprogramvare, kan HA aktiveres og konfigureres på en slik måte at hvis en server eller virtuell maskin mislykkes i klyngen, starter den automatisk på et annet medlem av klyngen. Det er verdt å klargjøre at HA ikke er beregnet på misjonskritiske VM-er (virtuelle maskiner). Så den estimerte tiden uten service vil være: "Starte operativsystemet + Starte tjenestene".
Antall vertsfeil som støttes av klyngen
Vi har X mengde virtuelle maskiner fordelt på Y -servere i en klynge.
Hvor mange verter kan mislykkes uten å påvirke tilgjengeligheten og ytelsen til vårt virtuelle miljø?
HA kan konfigureres til å støtte et bestemt antall serverfeil, og sikre at det er nok ressurser igjen i gjenopprettingen.
HA deler de tilgjengelige ressursene i en klynge med tanke på CPU og RAM som er konfigurert og konsumert av våre virtuelle maskiner på en veldig konservativ måte. Den tar den største konfigurerte CPU -reservasjonen til en hvilken som helst VM på hver vert i klyngen, og deretter den største minne -reservasjonen og dens overskudd. Hvis det ikke er konfigurert noen reservasjoner, vil det kreve minimum 32 Mhz per VM for CPU og 0 Mb RAM + overskudd.
Med disse tallene antar det at hver virtuell maskin bruker vil forbruke den CPU og minnet, så genererer den en verdi som kalles spillestørrelse. Med denne verdien er det bestemt hvor mange plasser som er tilgjengelige / brukt av hver vert.
Problemet oppstår når vi for eksempel har en enkelt maskin med stor CPU og minnereserve. Ved å ta konfigurerte reservasjoner er det svært sannsynlig at resten av våre virtuelle maskiner ikke virkelig trenger disse ressursene, noe som resulterer i færre spor for klyngen vår.
Andel klyngeressurser som kapasitet for feil
I motsetning til det forrige alternativet, fungerer denne veldig bra når du har VM -er med svært varierende CPU- og minnekonfigurasjoner.
Det er mulig å konfigurere prosentverdier for CPU og minne separat, på denne måten enda mer fleksibel og dermed spare ressurser. Dette er generelt den foretrukne metoden for å konfigurere HA.
Verter for failover
Dette er den typiske standby -klynge -konfigurasjonen. Dette alternativet er hovedsakelig gitt siden noen organisasjoner opprettholder retningslinjer som indikerer at det må være servere i beredskap i tilfelle katastrofe. Siden VMware gjør god feiltoleransebehandling, er dette kanskje alternativet når det er mange ressurser … men definitivt ikke det beste.
vMotion: Levende migrasjoner
Live migrering lar deg flytte virtuelle maskiner fra en fysisk server til en annen mens du beholder nettverkstilkoblingen og identiteten din. Aktivt minne (kjørende prosesser) overføres over høyhastighetsnettverket. Hele prosessen tar mindre enn 5 sekunder på et gigabit -nettverk.
Det er mulig å flytte VM, filene den bruker, eller begge deler, og prosedyren kan utføres med maskinen på eller av. I sistnevnte tilfelle kaller vi det "kald migrasjon", og hvis maskinen kjører, kaller vi den vMotion.
Bruksområder og fordeler med vMotion
- VM -omorganiseringog dermed optimalisere ressursene. Fjern dem fra servere som er utsatt for feil eller mettet.
- Automatisk optimalisering av tilgjengelige ressurser (Jeg jobber sammen med Dynamic Resource Scheduler eller DRS).
- Gjøre vedlikehold av den underliggende infrastrukturen ikke behov for vedlikeholdsplanlegging eller forretningsavbrudd.
Hver komponent i VM -helse håndteres annerledes under migrering. Den generelle konfigurasjonen er den enkleste, den beveger seg ikke, men gjenopprettes på måldatamaskinen.
Siden disken ikke kan gjenopprettes på så kort tid, er det nødvendig å ha delt lagringsplass. Den nåværende tilstanden til minnet blir gradvis kopiert til destinasjonsverten. På slutten av kopien sammenlignes de eksisterende forskjellene som oppstod under overføringen, tilstanden til kilde -VM er frosset og operativsystemet er aktivert på destinasjons -VM .
Fordi i noen tilfeller ikke muligheten til å starte maskinen på nytt er ideell, for misjonskritiske har vi Feiltoleranse. Det som er ønsket i disse tilfellene, slutter ikke å fungere når som helst, selv om verten svikter. Den eneste måten dette er mulig på er hvis VM kjørte to steder samtidig. Den er konfigurert på virtuelt maskinnivå og vil generere en eksakt kopi av VM, og beholde den 100% replikert til enhver tid på en annen server, så i tilfelle en maskinvarefeil, vil tvillingen rett og slett fortsette å fungere uten tap av informasjon. Interessant, ikke sant?
Hvis det bare handlet om ressurser, ville vi aktivert FT i alle virtuelle maskiner i datasenteret vårt, men i tidligere versjoner av vSphere møtte vi noen begrensninger, de viktigste: Det var ikke mulig å aktivere FT i maskiner som brukte mer enn en virtuell prosessor. Heldigvis støtter den i den siste versjonen av produktet opptil 4 virtuelle prosessorer samtidig per beskyttet maskin, men lisensiering må vurderes:
Antall vCPUer som støttes av en FT-aktivert VM er begrenset av lisensnivået som er kjøpt for vSphere.
Feiltoleranse støttes som følger:
- vSphere Standard og Enterprise. Tillater opptil 2 vCPUer.
- vSphere Enterprise Plus. Tillater opptil 4 vCPUer.
Det er ikke det eneste kravet til systemet.
OppbevaringVM må ha delt lagring. Det er ikke mulig å bruke fysisk RDM (Raw Devide Mapping).
NettDet er nødvendig å ha minst to virtuelle kort (vmnics), ett for vMotion og det andre (10 gbps) for FT Logging. Det er et nytt krav i versjon 6 (tidligere var 1 gbps plater nødvendig)
ProsessorProsessorer og operativsystemer må være kompatible med FT (og med hverandre).
Begrensninger
- Det er ikke mulig å ta øyeblikksbilder av VMene som er beskyttet med FT, og de må slettes før du aktiverer denne funksjonen.
- Virtuelle disker (VMDK) større enn 2 TB.
- Det er en liste over spesifikke enheter og funksjoner i VMware -dokumentasjonen.
Og det er også en begrensning på antall VM -er per server: maksimalt 4 beskyttede maskiner per vert eller 8 beskyttede vCPU -er (hvilken grense som kommer først). Disse maksimumene inkluderer den primære og sekundære maskinen (og vCPU -er)
Forskjeller mellom FT -arv (tidligere) og nåværende
IPv6
Legacy FT = Støttes ikke av nettverkskort som er konfigurert for FT -logging FT = Støttes
VStorage APIer - Sikkerhetskopiering med databeskyttelse
Eldre FT = Ikke støttet FT = Støttes
Virtuell disk
Legacy FT = EZT (Eager Zeroed Thick) FT = Alle typer, inkludert tykt og tynt
VMK -redundans (virtuell disk)
Legacy FT = Enkeltkopi FT = Primær- og sekundærmaskinene opprettholder uavhengige kopier, dette gjør at de kan lagres i forskjellige datalagre og øke redundansen
Båndbredde på nettverksplate
Legacy FT = Dedikert 1-Gb NIC anbefalt FT = Dedikert 10 Gb NIC anbefalt
CPU og vertskompatibilitet
Legacy FT = Krever samme CPU -modell og familie. Nesten identiske vSphere -versjoner FT = CPUer må være kompatible med vSphere vMotion eller EVC. VSphere -versjonen må være kompatibel med vSphere vMotion
Aktiver / deaktiver FT mens maskinen er i gang
Legacy FT = Ikke alltid støttet FT = Støttes
Husk at FT beskytter mot server maskinvarefeil, ikke operativsystemer eller applikasjonsfeil.
vCenter Server Watchdog det er en innebygd funksjonalitet av versjon 6.x. Den sjekker jevnlig statusen til tjenestene som utgjør vCenter, den starter på nytt administrasjonsprosessene eller VM om nødvendig.
