VMware

Četvrti deo: Praktikumi, laboratorije i završni projekti
Operativna validacija i game day – kvar, oporavak, dokazi i retrospektiva
XIII. Laboratorijsko okruženje i integrisani projekti
Dodatak 3. Operativna validacija i game day – kvar, oporavak, dokazi i retrospektiva

Pouzdano VMware okruženje nije ono u kome se kvar još nije dogodio, već ono za koje tim može da dokaže da kvar prepoznaje, ograničava, bezbedno oporavlja i pretvara u trajno poboljšanje. Ovaj dodatak je završni integrisani praktikum tutorijala: laboratorija iz Dodatka 1 i model upravljivog enterprise okruženja iz Dodatka 2 sada se proveravaju kontrolisanim game day vežbama. Posmatra se ceo operativni sistem rada — ljudi, procedure, vCenter Server, ESXi, vSphere HA, mreža, storage, gostujući sistem, aplikacija, monitoring, backup i evidencija promene.

Game day je vremenski ograničena i unapred odobrena vežba u kojoj se uvodi poznat poremećaj ili simulira gubitak zavisnosti, a zatim proveravaju detekcija, eskalacija, tehnički oporavak i komunikacija. To nije nekontrolisano „rušenje sistema”. U produkciji se sprovodi tek kada postoje vlasnik usluge, odobren opseg, održavan backup, potvrđen put povratka, kriterijumi za trenutno zaustavljanje i osoba ovlašćena da prekine eksperiment. Prvi ciklus se uvek izvodi u izolovanoj laboratoriji.

1. Ishodi učenja i operativni kriterijum uspeha

Po završetku lekcije administrator treba da ume da prevede poslovni zahtev u proverljivu hipotezu, zabeleži početno stanje, uvede kontrolisan kvar, očuva vremenski sled dokaza, razlikuje restart virtuelne mašine od oporavka usluge, izmeri MTTD i MTTR, sprovede bezbedan rollback i napiše retrospektivu bez traženja krivca. Vežba je uspešna i kada otkrije slabost, pod uslovom da je blast radius ostao u odobrenim granicama, da su podaci sačuvani i nalaz pretvoren u odgovornu korektivnu meru.

Pojam Šta meri ili ograničava Prihvatljiv dokaz
Blast radius Najveći dozvoljeni skup hostova, VM-ova, mreža, datastore-ova i korisnika koje vežba može da pogodi. Imenovan inventar i eksplicitna lista objekata izvan opsega.
MTTD Vreme od početka poremećaja do pouzdane detekcije. Sinhronizovani timestamp injekcije kvara i alarma ili tiketa.
MTTA Vreme do potvrde da je odgovorna osoba preuzela incident. Audit trag ili vreme preuzimanja tiketa.
MTTR Vreme do potvrđenog oporavka usluge, ne samo infrastrukture. Sintetički test, aplikaciona transakcija i stabilne metrike.
RPO Najveći prihvatljiv gubitak podataka izražen vremenom. Poređenje poslednje potvrđene transakcije pre kvara i podataka posle oporavka.
RTO Najduže prihvatljivo vreme nedostupnosti usluge. Vremenska linija od prekida do poslovno potvrđene funkcionalnosti.

2. Granice testa: laboratorijska simulacija, produkciona vežba i incident

Ista radnja nema isti rizik u svim okruženjima. Gašenje laboratorijskog ESXi hosta sa dve testne VM može dokazati HA oporavak; prekid oba management uplink-a produkcionog hosta može aktivirati isolation response, izgubiti administrativni pristup, poremetiti storage i produžiti zadržavanje lock-a. Zato se bira najmanje destruktivan fault injection koji proverava istu hipotezu.

Nivo Dozvoljena proba Obavezna zaštita Nije prihvatljivo
Izolovana laboratorija Gašenje testnog servisa ili hosta, uklanjanje jednog redundantnog uplink-a, restore u novu lokaciju. Out-of-band pristup, kopija konfiguracije, početno stanje i rollback. Eksperiment koji može zahvatiti produkcioni VLAN ili storage.
Preprodukcija Realističan kvar jedne redundantne komponente i aplikacioni test. Odobrena promena, monitoring i prisutan vlasnik aplikacije. Maskiranje alarma tako da se ne proveri eskalacija.
Produkcija Tabletop, zatim ograničena reverzibilna proba bez ugrožavanja podataka. Formalni change, stop authority, maintenance window i vendor support kada je potreban. Prvi pokušaj procedure ili istovremeni test više kvarova.
Stvarni incident Dijagnostika i korekcije potrebne za stabilizaciju. Incident commander, dnevnik odluka i očuvanje dokaza. Nastavljanje eksperimenta.

Snapshot nije backup niti podrazumevani rollback. Kratkotrajan snapshot pomaže kod reverzibilne promene u jednoj VM, ali ne štiti od gubitka datastore-a, ne zamenjuje aplikaciono konzistentan backup i uvećava I/O i delta disk. Restore se testira u zasebnoj lokaciji ili izolovanoj mreži.

3. Dizajn game day-a: od poslovne tvrdnje do hipoteze

Tvrdnja „HA radi” nije dovoljna. Proverljiva hipoteza glasi: „Ako jedan ESXi host iznenada postane nedostupan, VM gd-web01 biće automatski uključena na preživelom hostu u roku od 180 sekundi, HTTPS proba će ponovo davati status 200 u roku od 300 sekundi, bez gubitka poslednje potvrđene testne transakcije.” Ona navodi stimulus, granicu otkaza, objekt, mehanizam, vreme i dokaz na nivou aplikacije.

3.1. Eksperimentalni karton

3.2. Minimalna laboratorijska topologija

vCenter Server: vcsa.lab.example
Cluster: LAB-CL01 (HA uključen)
ESXi: esx01.lab.example, esx02.lab.example
Management: redundantne putanje ili out-of-band konzola
Shared datastore: DS-LAB01
Test VM: gd-web01, VMware Tools aktivan, aplikaciona health proba
Observer: admin01 sa VCF PowerCLI i sinhronizovanim vremenom
Backup: potvrđena restore tačka za gd-web01
Izvan opsega: produkcioni VLAN-ovi, datastore-ovi i management VM

Klaster sa dva hosta može demonstrirati restart, ali ima malu marginu kapaciteta. Admission Control mora pokazati da preživeli host ima resurse. Ako je vCenter na testiranom klasteru, unapred se proveravaju njegova lokacija, DNS i direktan pristup ESXi Host Client-u. HA može nastaviti određene funkcije bez aktivnog vCenter-a, ali vidljivost i orkestracija postaju ograničene.

4. Pre-flight validacija i paket početnih dokaza

Dokazi se prikupljaju pre promene stanja. Inventar potvrđuje verzije i build brojeve, licencu, HA/DRS, admission control, datastore, putanje, VM restart priority, VM/Host pravila, kapacitet, alarme, VMware Tools i aplikacioni health. Proactive HA, DRS automatizacija, vSAN politike i orkestrisani DR nisu sinonimi za osnovni HA restart i zavise od platforme, integracije i licence.

4.1. Read-only VCF PowerCLI snimak

Primer se izvršava na administrativnoj stanici sa aktuelnim VCF PowerCLI modulima i nalogom sa najmanjim privilegijama za čitanje. Ne menja vSphere stanje; direktorijum treba zaštititi jer sadrži operativne metapodatke.

$vc = "vcsa.lab.example"
$clusterName = "LAB-CL01"
$evidenceRoot = Join-Path $PWD ("game-day-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
New-Item -ItemType Directory -Path $evidenceRoot | Out-Null

Connect-VIServer -Server $vc
$cluster = Get-Cluster -Name $clusterName

Get-VMHost -Location $cluster |
  Select-Object Name, ConnectionState, PowerState, Version, Build, CpuUsageMhz, MemoryUsageGB |
  Export-Csv (Join-Path $evidenceRoot "hosts.csv") -NoTypeInformation -Encoding UTF8

Get-VM -Location $cluster |
  Select-Object Name, PowerState, VMHost, NumCpu, MemoryGB,
    @{N="ToolsStatus";E={$_.ExtensionData.Guest.ToolsStatus}} |
  Export-Csv (Join-Path $evidenceRoot "vms.csv") -NoTypeInformation -Encoding UTF8

Get-Datastore -RelatedObject $cluster |
  Select-Object Name, Type, State, CapacityGB, FreeSpaceGB |
  Export-Csv (Join-Path $evidenceRoot "datastores.csv") -NoTypeInformation -Encoding UTF8

Get-AlarmDefinition -Entity $cluster -Enabled $true |
  Select-Object Name, Description |
  Export-Csv (Join-Path $evidenceRoot "enabled-alarms.csv") -NoTypeInformation -Encoding UTF8

Get-VIEvent -Entity $cluster -Start (Get-Date).AddMinutes(-30) -MaxSamples 5000 |
  Select-Object CreatedTime, UserName, FullFormattedMessage |
  Export-Csv (Join-Path $evidenceRoot "events-before.csv") -NoTypeInformation -Encoding UTF8

Get-VIEvent može vratiti ograničen broj zapisa, pa se vremenski prozor i -MaxSamples biraju svesno. Sačuvati treba i ID promene, verziju runbook-a, HA konfiguraciju i aplikacionu probu. Lozinke, session cookie-je i private key materijal ne stavljati u tiket.

4.2. Vreme i marker eksperimenta

Korelacija zahteva ispravno vreme na vCenter-u, ESXi-u, gostu i observer-u. Na odobrenom, vremenski ograničenom ESXi Shell-u stanje se čita prve dve komande; treća samo dodaje marker u syslog.

esxcli system time get
esxcli system ntp get
esxcli system syslog mark --message="GAME-DAY GD-2026-03 START host=esx01"

Ako SSH nije dozvoljen, vreme i događaji se proveravaju kroz vSphere Client i centralni syslog. Privremeno uključen SSH na kraju se isključuje i promena evidentira.

5. Telemetrija, logovi i lanac čuvanja dokaza

Izvor Šta potvrđuje Korelacija
vCenter Tasks, Events i Alarms Izvršioca, vreme promene, HA događaje i reconnect. vSphere Client ili Get-VIEvent; change ID i marker.
/var/run/log/fdm.log FDM election, heartbeat, isolation i failover odluke. Incidentni prozor na svim relevantnim hostovima.
/var/run/log/hostd.log i vpxa.log Lokalne host operacije i vezu sa vCenter-om. vpxd.log i mrežni događaji.
/var/run/log/vmkernel.log Storage putanje, uređaje, drajvere i kernel događaje. Uređaj, vmnic ili naa ID plus vreme.
/var/log/vmware/vpxd/vpxd.log na VCSA vCenter servisne operacije i host komunikaciju. VCSA/support bundle i vCenter događaji.
Guest, aplikacija i monitoring Start servisa, zahtev, podatke i korisnički uticaj. Request ID i zajednički vremenski standard.

Na savremenom ESXi-u primarne lokacije su pod /var/run/log; starije reference često prikazuju /var/log ili simboličku vezu. Zvanična KB matrica za verziju ima prednost. Support bundle se prikuplja što pre jer rotacija uklanja prozor. Povećanje log nivoa, restart hostd/vpxa ili ponovno konfigurisanje HA nisu početne dijagnostičke radnje: menjaju stanje i mogu ukloniti dokaz.

6. Praktikum I – aplikaciona degradacija

Cilj. Proveriti detekciju prekida jedne testne usluge i razlikovati dostupnost VM-a od dostupnosti aplikacije. Rizik je nizak jer se zaustavlja samo namenski servis u gd-web01.

Preduslovi. VMware Tools, testna HTTPS stranica, monitoring sa poznatim intervalom i backup. Operator ima guest privilegiju; vSphere administrativni nalog nije potreban.

  1. Potvrditi tri uzastopne read-only probe:
for i in 1 2 3; do
  date --iso-8601=seconds
  curl --fail --silent --show-error --max-time 5 https://gd-web01.lab.example/health
  sleep 5
done
  1. U testnoj VM izvršiti sudo systemctl stop nginx. Ovo menja stanje; ne primenjivati na zajedničkoj usluzi.
  2. Meriti vreme do neuspeha probe, alarma i preuzimanja. Prvo proveriti DNS, TCP, VM i tek zatim guest servis.
  3. Izvršiti sudo systemctl start nginx, proveriti systemctl is-active nginx i ponoviti probe.
  4. Sačuvati alarm, događaj, probe i guest log istog prozora.

Rezultat. VM ostaje uključena, aplikacija pada, a monitoring prijavljuje servisni problem. Ako alarm ne stigne, proveriti pravilo, interval, dostavu i silence stanje. Ako se servis ne pokrene, čitati systemctl status i journalctl -u nginx --since; ne restartovati celu VM bez dokaza. Završetak zahteva stabilnu probu, zatvoren alarm i izmerene MTTD/MTTR.

7. Praktikum II – gubitak hosta i vSphere HA oporavak

Hipoteza. Gubitak jednog laboratorijskog hosta pokreće HA restart testne VM na drugom hostu i aplikacija se vraća unutar RTO-a. HA restart nije vMotion: memorijsko stanje se ne prenosi, gost se podiže ponovo, a aplikacija obnavlja servis.

Rizik. Visok za laboratoriju i neprihvatljiv kao prvi produkcioni test. Ne izvlačiti napajanje bez out-of-band pristupa. Ne prekidati management mrežu ako uplink nosi storage. Prvo se radi tabletop, zatim planirano gašenje laboratorijskog hosta; simulacija iznenadnog kvara sledi samo prema zvaničnom Broadcom postupku.

7.1. Preduslovi

7.2. Koraci

  1. Pokrenuti kontinuiranu aplikacionu probu i zabeležiti baznu liniju.
  2. Potvrditi trenutni host VM-a, restart priority, događaje i alarme.
  3. Lead izgovara „inject”; operator izvršava samo odobren laboratorijski postupak gubitka hosta.
  4. Observer prati stanje hosta, HA događaj, power-on VM-a, VMware Tools i aplikaciju bez promene stanja.
  5. Vlasnik po oporavku proverava staru i novu testnu transakciju.
  6. Host vratiti kontrolisano; pre workload-a proveriti management, NTP, storage, uplink, HA agent i hardver.

Očekivani rezultat. HA registruje kvar, bira kompatibilan host i uključuje VM. RTO se zaustavlja tek kada prođe poslovna provera, ne kada power state postane zelen.

7.3. Kada VM nije restartovana

Sloj Dokaz Bezbedna radnja
Obim Jedna VM, host ili klaster? Tasks/Events/Alarms; ne menjati više objekata.
HA odluka Failure, isolation ili partition; postoji li master? Korelirati fdm.log svih hostova.
Resursi Admission control, rezervacije ili memorija? Ne isključivati admission control kao prečicu.
Kompatibilnost Pravilo, uređaj, mreža ili datastore vezuju VM? Dokumentovati constraint i kasnije korigovati dizajn.
Lock/storage Originalni host drži lock ili datastore nije dostupan? Potvrditi stanje pre lock postupka; eskalirati uz bundle.
Aplikacija VM radi, ali servis ili baza nisu spremni? Preći na guest runbook; ne rekonfigurisati HA.

Rollback. Ako HA ne vrati VM, prekinuti eksperiment. Originalni host vratiti samo ako je bezbedno; potvrditi storage i odsustvo paralelne instance pre ručnog power-on-a. Nikada ne uključivati istu VM sa dve lokacije niti nasilno uklanjati lock bez potvrde uzroka.

8. Praktikum III – mrežna redundansa bez totalne izolacije

Cilj. Potvrditi da gubitak jednog redundantnog uplink-a ne prekida management ili testni VM saobraćaj i da alarm vidi degradaciju. Ovo nije host isolation test; isolation zavisi od isolation adresa, datastore heartbeat-a i isolation response politike.

Preduslovi. Dva nezavisna uplink-a, ispravan teaming, dosledni VLAN trunk-ovi, out-of-band pristup i potvrda da storage nije na jedinoj istoj putanji. LACP i vDS moraju biti usaglašeni sa fizičkim switch-em.

esxcli network nic list
esxcli network ip interface list
esxcli network vswitch standard uplink list

Komande su read-only; poslednja važi za vSphere Standard Switch. Za distribuirani switch koristi se vSphere Client i podržana dijagnostika.

  1. Pokrenuti management i aplikacione probe; zabeležiti latenciju i packet loss.
  2. Na jednom unapred odabranom laboratorijskom portu izvršiti shutdown ili odvajanje. Drugi uplink i out-of-band moraju biti potvrđeni.
  3. Potvrditi alarm, prelaz saobraćaja i odsustvo VLAN gubitka.
  4. Vratiti port, sačekati stabilizaciju i proveriti flap ili neželjeni failback.

Rezultat. Jedna putanja pada, servis ostaje dostupan, a monitoring prijavljuje smanjenu redundansu. Ako padne sve, uzrok može biti lažna redundansa, pogrešan trunk, active/standby redosled, LACP nesaglasnost ili zajednička fizička tačka otkaza. Workaround je vraćanje porta; trajna mera je korekcija dizajna i ponovljeni test.

9. Praktikum IV – restore kao dokaz zaštite podataka

Cilj. Dokazati da restore tačka proizvodi funkcionalnu izolovanu kopiju VM-a i da su RPO, integritet i konzistentnost poznati. Uspešan backup job nije dokaz oporavljivosti.

Preduslovi. Koristi se podržano backup rešenje. Restore ide kao gd-web01-restore u izolovanu port grupu. Sprečavaju se dupli IP/DNS, domain trust konflikt, slanje poruka i pristup produkcionoj bazi.

  1. Zabeležiti restore point, timestamp, tip konzistentnosti i poslednju očekivanu transakciju.
  2. Obnoviti VM u izolovani folder, resource pool, datastore i mrežu, bez konflikta identiteta.
  3. Pre power-on-a pregledati adaptere i automatizacije; zatim meriti Tools, servis i aplikaciju.
  4. Vlasnik potvrđuje konzistentnost, podatke i kontrolisan testni upis.
  5. Sačuvati session log, restore point ID, trajanje i odstupanje od RPO/RTO.

Kriterijum. Kopija se pokreće bez konflikta, aplikaciona provera prolazi i podaci odgovaraju cilju. Bootabilna VM čija baza zahteva recovery samo je delimičan uspeh.

Čišćenje. Isključiti kopiju i ukloniti je tek po odobrenju. Brisanje mora ciljati samo testnu kopiju. Povlače se privremeni DNS, firewall, mount i kredencijali; originalni backup se ne briše.

10. Incident response: dokaz pre promene

Kada ponašanje izađe iz okvira, game day prelazi u incident. Lead zaustavlja injekciju, incident commander preuzima prioritete, a zapisničar nastavlja vremensku liniju. Redosled je: zaštita podataka, ograničenje obima, dokazi, hipoteza, najmanje invazivna korekcija, validacija usluge i potom trajna promena.

Element Primer za „VM se nije oporavila”
Simptom HTTPS ne uspeva; VM je isključena.
Obim/posledica Jedna testna usluga; RTO prekoračen.
Neposredni uzrok HA nije našao host sa pristupom datastore-u.
Osnovni uzrok VM je na host-local datastore-u, a pre-flight to nije proveravao.
Workaround Bezbedno vratiti host i uključiti VM posle provere lock-a.
Trajna mera Migrirati na shared storage i dodati policy/pre-flight kontrolu.
Dokaz zatvaranja Ponovljena vežba prolazi RTO i inventar više ne nalazi odstupanje.

11. Automatska post-check evidencija

Primer čita stanje posle vežbe i pravi porediv skup dokaza. Ne menja vSphere objekte.

$end = Get-Date
$start = $end.AddHours(-2)

Get-VIEvent -Entity $cluster -Start $start -Finish $end -MaxSamples 10000 |
  Sort-Object CreatedTime |
  Select-Object CreatedTime, UserName, FullFormattedMessage |
  Export-Csv (Join-Path $evidenceRoot "events-after.csv") -NoTypeInformation -Encoding UTF8

Get-VM -Location $cluster |
  Select-Object Name, PowerState, VMHost,
    @{N="ToolsRunning";E={$_.ExtensionData.Guest.ToolsRunningStatus}} |
  Export-Csv (Join-Path $evidenceRoot "vms-after.csv") -NoTypeInformation -Encoding UTF8

Get-VMHost -Location $cluster |
  Select-Object Name, ConnectionState, PowerState |
  Export-Csv (Join-Path $evidenceRoot "hosts-after.csv") -NoTypeInformation -Encoding UTF8

Get-FileHash -Algorithm SHA256 (Join-Path $evidenceRoot "*.csv") |
  Select-Object Path, Algorithm, Hash |
  Export-Csv (Join-Path $evidenceRoot "sha256-manifest.csv") -NoTypeInformation -Encoding UTF8

Disconnect-VIServer -Server $vc -Confirm:$false

Hash pokazuje da datoteke kasnije nisu neopaženo promenjene, ali ne dokazuje potpunost podataka. Paket navodi izvor, autora, zonu, prozor i ograničenja. Pre deljenja uklanjaju se tajne i nepotrebni lični podaci.

12. Retrospektiva bez krivice

Retrospektiva se radi dok je vremenska linija sveža, posle stabilizacije. „Bez krivice” ne znači bez odgovornosti: razume se zašto je odluka delovala razumno, koja barijera je nedostajala i ko završava merljivu korekciju.

  1. Činjenice: redosled događaja i izvor timestamp-a.
  2. Odstupanje: potvrđena, delimična ili opovrgnuta hipoteza.
  3. Faktori: dizajn, konfiguracija, dokumentacija, monitoring i komunikacija.
  4. Dobre kontrole: šta je ograničilo posledicu.
  5. Mere: vlasnik, prioritet, rok, rizik i dokaz završetka.
  6. Ponovni test: datum i scenario validacije mere.
Loša mera Proverljiva mera
„Obučiti administratore.” Ažurirati HA runbook; dva administratora ga izvršavaju bez usmenih dopuna uz zapis.
„Popraviti monitoring.” Dodati HTTPS probu na 30 sekundi, alarm posle tri neuspeha i dokazati MTTD.
„Povećati kapacitet.” Obezbediti rezervu za gubitak jednog hosta i dokazati pre-flight izveštajem i ponovnim testom.

13. Administratorske prakse

14. Završna kontrolna tačka

Administrator je završio praktikum kada može da priloži:

Zaključak

Operativna validacija zatvara krug tutorijala. HA, DRS, mreža, storage, backup, monitoring, identitet, automatizacija, promene i incident response postaju jedan proverljiv sistem. Ključna veština nije brzo izvršavanje komande, već kontrola rizika: razumeti zavisnosti, izabrati najmanje opasan test, sačuvati dokaze, zaustaviti rast opsega, potvrditi oporavak na nivou korisničke funkcije i pretvoriti nalaz u trajnu meru.

Zrela organizacija ne koristi game day za unapred očekivani „zeleni” izveštaj, već da bezbedno otkrije gde se dokumentacija, konfiguracija i stvarnost razilaze. Tek ponovljiva vežba, merljiv oporavak i zatvorena korektivna mera dokazuju da je VMware okruženje zaista upravljivo i otporno.

← Prethodni dodatak Povratak na sadržaj Zaključak →