Afhængigt af hvor kraftfuldt det udstyr vi har og de nødvendige ressourcer til vores systemer, har vi et gennemsnitligt forhold mellem virtuelle maskiner pr. Server.
Tag for eksempel den planlagte vedligeholdelse af en server i Computer Center. For nogle år siden, hvis dette ikke var en del af en klynge, ville systemet i udstyret blive taget offline, følgelig ville brugerne også blive påvirket og / eller personalet involveret i vedligeholdelsen skulle arbejde i vinduer med reduceret tid (for ikke at sige ubehageligt).
I tilfælde af et virtualiseret miljø kan virtuelle maskiner simpelthen "flyttes eller migreres" til et andet medlem af en klynge, og udstyret kan lukkes ned for at arbejde på det. Problem løst.
Lad os begynde at se situationer, hvor manglen på service ikke er programmeret.
Overvågning af virtuel maskine og applikationer
Hver gang vi opretter en virtuel maskine, anbefales det at installere et kompendium af applikationer og drivere, der optimerer den virtuelle hardwares adfærd i sin helhed (tilgængelig til Windows, Mac OS, Linux og andet OS). Disse værktøjer, kaldet VMTools, inkluderer blandt andet muligheden for, at værten kan overvåge den virtuelle maskine (gennem hjerteslag, som i klynger). Hvis det ikke reagerer inden for en bestemt periode, genstarter det dit operativsystem.
En lignende sag sker med applikationsovervågning, men først skal du skaffe det relevante SDK (eller bruge et program, der understøtter VMware Application Monitoring).
Men … hvad sker der, hvis fejlen er hardware?
Klyngen nævnt ovenfor er det første lag af opløsningen.
Delt lagerHvor alle medlemmer af klyngen har adgang til virtuelle maskiner.
NetværkssamarbejdeKonfronteret med fejl i et bræt, fortsætter de resterende med at styre trafikken.
Flere stier (flervej)Til opbevaring optimerer de ikke kun adgangen, men giver også redundans.
Generelt formindsker disse tre teknologier det tidspunkt, hvor vores informationer er utilgængelige. Afhængigt af den licens vi har, kan vi nu også have to meget interessante funktioner: Høj tilgængelighed (HA) og fejltolerance (FT).
I begge tilfælde kræver vi en klynge med delt lagerplads. Uden behov for at installere yderligere software kan HA aktiveres og konfigureres på en sådan måde, at hvis en server eller virtuel maskine mislykkes i klyngen, starter den automatisk på et andet medlem af klyngen. Det er værd at præcisere, at HA ikke er beregnet til missionskritiske VM'er (virtuelle maskiner). Så den estimerede tid uden service vil være: "Start af operativsystemet + Start af tjenesterne".
Antal hostfejl, der understøttes af klyngen
Vi har X mængde virtuelle maskiner fordelt på Y -servere i en klynge.
Hvor mange værter kan mislykkes uden at påvirke tilgængeligheden og ydelsen af vores virtuelle miljø?
HA kan konfigureres til at understøtte et bestemt antal serverfejl og sikre, at der er tilstrækkelige ressourcer tilbage i gendannelsen.
HA skærer de tilgængelige ressourcer i en klynge under hensyntagen til CPU og RAM konfigureret og forbrugt af vores virtuelle maskiner på en meget konservativ måde. Det tager den største konfigurerede CPU -reservation af enhver VM på hver vært i klyngen og derefter den største hukommelsesreservation og dens overskud. Hvis der ikke er konfigureret nogen reservation, tager det mindst 32 Mhz pr. VM for CPU og 0 Mb RAM + dets overskud.
Med disse tal antager det, at hver virtuel maskine, der bruger, vil forbruge den CPU og hukommelse, så genererer den en værdi, der kaldes slotstørrelse. Med denne værdi bestemmes det, hvor mange slots der er tilgængelige / brugt af hver vært.
Problemet opstår, når vi for eksempel har en enkelt maskine med en stor CPU og hukommelsesreserve. Ved at tage konfigurerede reservationer er det meget sandsynligt, at resten af vores virtuelle maskiner ikke rigtig har brug for disse ressourcer, hvilket resulterer i færre slots til vores klynge.
Procentdel af klyngeressourcer som kapacitet til fejl
I modsætning til den tidligere mulighed fungerer denne meget godt, når du har VM'er med meget variabel CPU- og hukommelseskonfigurationer.
Det er muligt at konfigurere procentværdier for CPU og hukommelse separat, på den måde endnu mere fleksibel og dermed spare ressourcer. Dette er generelt den foretrukne metode til konfiguration af HA.
Værter til failover
Dette er den typiske standby -klynge -konfiguration. Denne mulighed er hovedsageligt givet, da nogle organisationer opretholder politikker, der angiver, at der skal være servere i standby i tilfælde af en katastrofe. Da VMware udfører god fejltolerancehåndtering, er dette måske en mulighed, når der er rigelige ressourcer … men bestemt ikke den bedste.
vMotion: Levende migrationer
Live migration giver dig mulighed for at flytte virtuelle maskiner fra en fysisk server til en anden, samtidig med at du opretholder din netværksforbindelse og identitet. Aktiv hukommelse (kørende processer) overføres over højhastighedsnetværket. Hele processen tager mindre end 5 sekunder på et gigabit -netværk.
Det er muligt at flytte VM'en, de filer, den bruger, eller begge dele, og proceduren kan udføres med maskinen til eller fra. I sidstnævnte tilfælde kalder vi det "kold migration", og hvis maskinen kører, kalder vi det vMotion.
Anvendelser og fordele ved vMotion
- VM -reorganiseringog dermed optimere ressourcer. Fjern dem fra servere, der er tilbøjelige til fejl eller mættet.
- Automatisk optimering af tilgængelige ressourcer (Jeg arbejder sammen med Dynamic Resource Scheduler eller DRS).
- Gør vedligeholdelse af den underliggende infrastruktur ikke behov for vedligeholdelsesplanlægning eller forretningsafbrydelse.
Hver komponent i VM -sundhed håndteres forskelligt under migrering. Den generelle konfiguration er den enkleste, den bevæger sig ikke, men genoprettes på målcomputeren.
Da disken ikke kan genskabes på så kort tid, er det nødvendigt at have delt lagerplads. Den aktuelle tilstand i hukommelsen kopieres gradvist til destinationsværten. I slutningen af kopien sammenlignes de eksisterende forskelle, der opstod under migrationen, tilstanden af kilde -VM er frosset, og operativsystemet aktiveres på destinations -VM .
Fordi i nogle tilfælde muligheden for at genstarte maskinen ikke er ideel, har vi til missionskritiske Fejltolerance. Det, der ønskes i disse tilfælde, stopper ikke på noget tidspunkt, selvom dets vært mislykkes. Den eneste måde, dette er muligt på, er, hvis VM kørte to steder på samme tid. Den er konfigureret på det virtuelle maskinniveau og genererer en nøjagtig kopi af VM, så den hele tiden bliver 100% replikeret på en anden server, så i tilfælde af en hardwarefejl vil dens tvilling simpelthen fortsætte med at fungere uden tab af information. Interessant, ikke?
Hvis det kun handlede om ressourcer, ville vi aktivere FT i alle virtuelle maskiner i vores datacenter, men i tidligere versioner af vSphere stødte vi på nogle begrænsninger, de vigtigste: Det var ikke muligt at aktivere FT i maskiner, der brugte mere end en virtuel processor. Heldigvis understøtter den i den nyeste version af produktet op til 4 virtuelle processorer samtidigt pr. Beskyttet maskine, men licensering skal overvejes:
Antallet af vCPU'er, der understøttes af en FT-aktiveret VM, er begrænset af licensniveauet, der er købt til vSphere.
Fejltolerance understøttes som følger:
- vSphere Standard og Enterprise. Tillader op til 2 vCPU'er.
- vSphere Enterprise Plus. Tillader op til 4 vCPU'er.
Det er ikke det eneste krav i systemet.
OpbevaringVM'er skal have delt lagerplads. Det er ikke muligt at bruge fysisk RDM (Raw Devide Mapping).
NetDet er nødvendigt at have mindst to virtuelle kort (vmnics), et til vMotion og det andet (10 gbps) til FT Logging. Det er et nyt krav i version 6 (tidligere var 1 gbps plader nødvendige)
ProcessorProcessorer og operativsystemer skal være kompatible med FT (og med hinanden).
Begrænsninger
- Det er ikke muligt at tage snapshots af de VM'er, der er beskyttet med FT, og de skal slettes, før denne funktion aktiveres.
- Virtuelle diske (VMDK) større end 2 Tb.
- Der er en liste over specifikke enheder og funktioner i VMware -dokumentationen.
Og der er også en begrænsning på antallet af VM'er pr. Server: maksimalt 4 beskyttede maskiner pr. Vært eller 8 beskyttede vCPU'er (den grænse, der kommer først). Disse maksimumsgrænser inkluderer den primære og sekundære maskine (og vCPU'er)
Forskelle mellem FT -arv (tidligere) og nuværende
IPv6
Legacy FT = Understøttes ikke af netværkskort, der er konfigureret til FT -logning FT = Understøttet
VStorage API'er - Backup med databeskyttelse
Legacy FT = Understøttes ikke FT = Understøttes
Virtuel disk
Legacy FT = EZT (Eager Zeroed Thick) FT = Alle typer, inklusive tykt og tyndt
VMDK -redundans (virtuel disk)
Ældre FT = Enkeltkopi FT = Primær- og sekundærmaskinerne vedligeholder uafhængige kopier, dette gør det muligt at gemme dem i forskellige datalagre og øge redundansen
Netværkspladens båndbredde
Legacy FT = Dedikeret 1-Gb NIC anbefales FT = Dedikeret 10-Gb NIC anbefales
CPU og vært kompatibilitet
Legacy FT = Kræver samme CPU -model og familie. Næsten identiske vSphere -versioner FT = CPU'er skal være kompatible med vSphere vMotion eller EVC. VSphere -versionen skal være kompatibel med vSphere vMotion
Aktiver / deaktiver FT, mens maskinen kører
Legacy FT = Understøttes ikke altid FT = Understøttes
Husk, at FT beskytter mod serverhardwarefejl, ikke operativsystemer eller applikationsfejl.
vCenter Server Watchdog det er en integreret funktionalitet af version 6.x. Det kontrollerer med jævne mellemrum status for de tjenester, der udgør vCenter, det genstarter administrationsprocesserne eller VM'en, hvis det er nødvendigt.
