Atkarībā no mūsu jaudīgā aprīkojuma un mūsu sistēmām nepieciešamajiem resursiem, mums būs vidēja virtuālo mašīnu attiecība uz serveri.
Piemēram, plānota servera apkope Datoru centrā. Pirms dažiem gadiem, ja tas nebūtu klasteru daļa, iekārtā esošā sistēma tiktu pārvietota bezsaistē, līdz ar to tiktu ietekmēti arī lietotāji un / vai apkopē iesaistītajam personālam būtu jāstrādā saīsinātos laika periodos (piemēram, neērti).
Virtualizētas vides gadījumā virtuālās mašīnas var vienkārši “pārvietot vai migrēt” uz citu klastera dalībnieku, un iekārtu var izslēgt, lai strādātu pie tās. Problēma atrisināta.
Sāksim redzēt situācijas, kad pakalpojumu trūkums nav ieprogrammēts.
Virtuālās mašīnas un lietojumprogrammu uzraudzība
Katru reizi, kad izveidojam virtuālo mašīnu, ieteicams instalēt lietojumprogrammu un draiveru apkopojumu, kas optimizē virtuālās aparatūras darbību kopumā (pieejama operētājsistēmai Windows, Mac OS, Linux un citām OS). Šie rīki, ko sauc par VMTools, cita starpā ietver iespēju saimniekdatoram uzraudzīt virtuālo mašīnu (ar sirdspukstiem, kā kopās). Ja tas nereaģē noteiktā laika periodā, tas restartē jūsu operētājsistēmu.
Līdzīgs gadījums notiek ar lietojumprogrammu uzraudzību, taču vispirms jums ir jāiegūst atbilstošs SDK (vai jāizmanto lietojumprogramma, kas atbalsta VMware lietojumprogrammu uzraudzību).
Bet … kas notiek, ja vaina ir aparatūrā?
Iepriekš minētā kopa ir pirmais šķīduma slānis.
Kopīga krātuveKur visiem klastera dalībniekiem ir piekļuve virtuālajām mašīnām.
Tīkla komandaSaskaroties ar viena dēļa kļūmi, pārējie turpina pārvaldīt satiksmi.
Vairāki ceļi (multipathing)Uzglabāšanai tie ne tikai optimizēs piekļuvi, bet arī nodrošinās atlaišanu.
Vispārīgi runājot, šīs trīs tehnoloģijas mazina laiku, kad mūsu informācija nav pieejama. Tagad, atkarībā no mūsu licencēšanas, mums var būt arī divas ļoti interesantas funkcijas: augsta pieejamība (HA) un kļūdu tolerance (FT).
Abos gadījumos mums ir nepieciešama kopa ar kopīgu krātuvi. Bez nepieciešamības instalēt papildu programmatūru, HA var iespējot un konfigurēt tā, ka, ja serverī vai virtuālajā mašīnā neizdodas klasteris, tas automātiski sāksies citā klastera dalībniekā. Ir vērts precizēt, ka HA nav paredzēts misijai kritiskiem VM (virtuālajām mašīnām). Tātad paredzamais laiks bez pakalpojuma būs: "Operētājsistēmas palaišana + pakalpojumu palaišana".
Klasteru atbalstīto resursdatora kļūmju skaits
Klasterī Y serveros ir izplatīts X virtuālo mašīnu daudzums.
Cik saimnieku var neizdoties, neietekmējot mūsu virtuālās vides pieejamību un veiktspēju?
HA var konfigurēt, lai atbalstītu noteiktu skaitu servera kļūmju, nodrošinot, ka atkopšanā ir palikuši pietiekami resursi.
HA sagriež klastera pieejamos resursus, ņemot vērā mūsu virtuālo mašīnu konfigurēto un patērēto CPU un RAM ļoti konservatīvā veidā. Tas aizņem lielāko konfigurēto CPU rezervāciju jebkuram VM katram kopas resursdatoram un pēc tam lielāko atmiņas rezervāciju un tās pārpalikumu. Ja nav konfigurēta rezervācija, CPU procesam būs nepieciešami vismaz 32 Mhz uz vienu VM un 0 Mb RAM + tā pārpalikums.
Izmantojot šos skaitļus, tiek pieņemts, ka katra virtuālā mašīna izmantos šo CPU un atmiņu, tad tā ģenerēs vērtību, ko sauc par slota lielumu. Izmantojot šo vērtību, tiek noteikts, cik laika nišu ir pieejams / izmanto katrs resursdators.
Problēma rodas, ja, piemēram, mums ir viena mašīna ar lielu CPU un atmiņas rezervi. Veicot konfigurētas rezervācijas, ļoti iespējams, ka pārējām mūsu virtuālajām mašīnām šie resursi nav īsti nepieciešami, kā rezultātā mūsu kopai ir mazāk laika.
Klasteru resursu procentuālā daļa kā spēju neveiksmēm
Atšķirībā no iepriekšējās iespējas, šī opcija darbojas ļoti labi, ja jums ir VM ar ļoti mainīgu CPU un atmiņas konfigurāciju.
Procesora un atmiņas procentuālās vērtības ir iespējams konfigurēt atsevišķi, tādējādi kļūstot vēl elastīgākam un tādējādi ietaupot resursus. Parasti šī ir vēlamā metode HA konfigurēšanai.
Saimnieki kļūmjpārlēcei
Šī ir tipiska gaidstāves kopas konfigurācija. Šī iespēja galvenokārt tiek dota, jo dažas organizācijas saglabā politiku, kas norāda, ka katastrofu gadījumā serveriem jābūt gaidīšanas režīmā. Tā kā VMware labi pārvalda kļūdu toleranci, varbūt tā būtu iespēja, ja resursi ir daudz … bet noteikti ne tie labākie.
vMotion: Dzīvas migrācijas
Tiešā migrācija ļauj pārvietot strādājošās virtuālās mašīnas no viena fiziskā servera uz citu, vienlaikus saglabājot tīkla savienojumu un identitāti. Aktīvā atmiņa (darbības procesi) tiek pārsūtīta pa ātrgaitas tīklu. Viss process gigabitu tīklā aizņem mazāk nekā 5 sekundes.
Ir iespējams pārvietot VM, tā izmantotos failus vai abus, un procedūru var veikt, ieslēdzot vai izslēdzot iekārtu. Pēdējā gadījumā mēs to saucam par "auksto migrāciju", un, ja mašīna darbojas, mēs to saucam par vMotion.
VMotion izmantošana un priekšrocības
- VM reorganizācija, tādējādi optimizējot resursus. Noņemiet tos no serveriem, kuriem ir tendence uz kļūmēm vai kuri ir piesātināti.
- Pieejamo resursu automātiska optimizācija (Es strādāju kopā ar Dynamic Resource Scheduler vai DRS).
- Vai infrastruktūras uzturēšana nav nepieciešama apkopes plānošana vai biznesa pārtraukšana.
Migrācijas laikā katra VM veselības sastāvdaļa tiek apstrādāta atšķirīgi. Vispārējā konfigurācija ir visvienkāršākā, tā nepārvietojas, bet tiek atkārtoti izveidota mērķa datorā.
Tā kā disku nevar izveidot no jauna tik īsā laikā, ir nepieciešama kopīga krātuve. Pašreizējais atmiņas stāvoklis pakāpeniski tiek kopēts uz galamērķa resursdatoru. Kopēšanas beigās tiek salīdzinātas migrācijas laikā radušās atšķirības, tiek iesaldēts avota VM stāvoklis un mērķa VM tiek aktivizēta operētājsistēma. .
Tā kā dažos gadījumos iespēja restartēt mašīnu nav ideāla, mums ir svarīgi uzdevumam Kļūdu tolerance. Šajos gadījumos vēlamais nepārtrauc darbu jebkurā laikā, pat ja tā saimniekdators neizdodas. Vienīgais veids, kā tas ir iespējams, ir tad, ja VM darbojās divās vietās vienlaikus. Tas ir konfigurēts virtuālās mašīnas līmenī un ģenerēs precīzu VM kopiju, saglabājot to 100% visu laiku atkārtotu citā serverī, tāpēc aparatūras kļūmes gadījumā tā dvīnis vienkārši turpinās darboties, nezaudējot informāciju. Interesanti, vai ne?
Ja runa būtu tikai par resursiem, mēs iespējotu FT visās mūsu datu centra virtuālajās mašīnās, bet iepriekšējās vSphere versijās mēs saskārāmies ar dažiem ierobežojumiem, vissvarīgākais: FT nebija iespējams iespējot mašīnās, kurās tika izmantotas vairākas virtuālās mašīnas procesors. Par laimi, jaunākajā produkta versijā tas vienlaikus nodrošina līdz 4 virtuālajiem procesoriem uz vienu aizsargātu mašīnu, tomēr licencēšana būs jāņem vērā:
Ar VT iespējotu VM atbalstīto vCPU skaitu ierobežo vSphere iegādāto licencēšanas līmenis.
Kļūdu tolerance tiek atbalstīta šādi:
- vSphere Standard un Enterprise. Atļauj līdz 2 vCPU.
- vSphere Enterprise Plus. Atļauj līdz 4 vCPU.
Tā nav vienīgā sistēmas prasība.
UzglabāšanaVM jābūt koplietotai krātuvei. Nav iespējams izmantot fizisko RDM (Raw Devide Mapping).
TīklsNepieciešamas vismaz divas virtuālās kartes (vmnics), viena vMotion un otra (10 gbps) FT reģistrēšanai. Tā ir jauna 6. versijas prasība (iepriekš bija nepieciešamas 1 gbps plāksnes)
ProcesorsProcesoriem un operētājsistēmām jābūt saderīgām ar FT (un savstarpēji).
Ierobežojumi
- Nav iespējams uzņemt ar FT aizsargātu VM momentuzņēmumus, un tie ir jāizdzēš pirms šīs funkcijas iespējošanas.
- Virtuālie diski (VMDK) ir lielāki par 2 TB.
- VMware dokumentācijā ir konkrētu ierīču un funkciju saraksts.
Un ir arī ierobežots VM skaits uz serveri: ne vairāk kā 4 aizsargātas mašīnas uz vienu resursdatoru vai 8 aizsargāti vCPU (atkarībā no tā, kurš ierobežojums ir pirmais). Šie maksimumi ietver primāro un sekundāro mašīnu (un vCPU)
Atšķirības starp FT mantojumu (iepriekšējo) un pašreizējo
IPv6
Legacy FT = Neatbalsta tīkla kartes, kas konfigurētas FT reģistrēšanai FT = Atbalstīts
VStorage API - dublēšana ar datu aizsardzību
Legacy FT = Neatbalsta FT = Atbalstīts
Virtuālais disks
Legacy FT = EZT (Eager Zeroed Thick) FT = Visi veidi, ieskaitot biezu un plānu
Vmdk dublēšana (virtuālais disks)
Mantotā FT = viena kopija FT = primārā un sekundārā iekārta saglabā neatkarīgas kopijas, kas ļauj tās uzglabāt dažādās datu vietās un palielināt dublēšanos
Tīkla plāksnes joslas platums
Mantots FT = ieteicams 1 Gb NIC, ieteicams FT = Ieteicams 10 Gb NIC
CPU un resursdatora saderība
Legacy FT = Nepieciešams tāds pats CPU modelis un saime. Gandrīz identiskām vSphere versijām FT = CPU jābūt saderīgām ar vSphere vMotion vai EVC. VSphere versijai jābūt saderīgai ar vSphere vMotion
Aktivizējiet / deaktivizējiet FT, kad mašīna darbojas
Legacy FT = Ne vienmēr tiek atbalstīts FT = Atbalstīts
Atcerieties, ka FT aizsargā pret servera aparatūras kļūmēm, nevis operētājsistēmu vai lietojumprogrammu kļūmēm.
vCenter servera sargsuns tā ir 6.x versijas iegultā funkcionalitāte. Tā periodiski pārbauda vCenter veidojošo pakalpojumu statusu, nepieciešamības gadījumā restartēs administrēšanas procesus vai VM.
