VMware

Pouzdana VMware administracija ne meri se time koliko je promena izvršeno, već koliko je promena uvedeno bez neplaniranog prekida, bez gubitka podataka i sa dokazom da je usluga posle intervencije zaista ispravna. Ova lekcija povezuje lifecycle postupke iz lekcije 41, kontrolu pristupa i audit iz lekcija 42–43, automatizaciju iz lekcije 44 i kapacitet iz lekcije 45 u jedinstven operativni tok. Taj tok počinje pre prvog klika, traje tokom celog prozora održavanja i završava se tek kada su tehnički i poslovni kriterijumi prihvatanja potvrđeni.

Change management je upravljački proces kojim se promena identifikuje, procenjuje, odobrava, planira, izvršava, proverava i zatvara. Maintenance mode je tehničko stanje hosta ili drugog resursa u kome se workload uklanja ili sprečava njegovo normalno izvršavanje radi bezbednog održavanja. Ta dva pojma nisu sinonimi: host može biti u maintenance mode-u, a da promena i dalje bude loše vođena; obrnuto, neke kontrolisane promene ne zahtevaju maintenance mode. Rollback nije improvizovano „vrati kako je bilo”, nego unapred testiran postupak sa jasnim okidačem, vlasnikom, vremenom potrebnim za oporavak i tačno određenom tačkom povratka.

1. Promena kao kontrolisan operativni ciklus

Svaka promena prelazi kroz ista logička vrata: zahtev i poslovno obrazloženje; analiza uticaja i rizika; tehnički plan; odobrenje; pre-check; izvršenje; post-check; odluka o uspehu ili rollback-u; dokumentovanje i zatvaranje. U enterprise okruženju ova vrata mogu biti implementirana u ITSM sistemu i formalnom CAB procesu (Change Advisory Board), ali alat ne zamenjuje inženjersku procenu. Dobar zapis promene omogućava drugom kvalifikovanom administratoru da razume nameru, ponovi korake, prepozna tačku zaustavljanja i obnovi stanje bez nagađanja.

Klasifikacija i rizik

Standardna promena je niskorizična, ponovljiva i unapred odobrena samo ako je njen tačan postupak već dokazan. Normalna promena prolazi procenu i odobrenje primereno riziku. Hitna promena skraćuje rokove radi zaštite servisa ili zatvaranja kritične ranjivosti, ali ne ukida beleženje, razdvajanje dužnosti, validaciju ni naknadni pregled. „Hitno” ne znači „bez plana”. Promena mora biti razložena na najmanji razumno izolovan talas: jedan host, jedan klaster ili jedna upravljačka komponenta, uz posmatranje između talasa. Time se smanjuje blast radius i čuva mogućnost zaustavljanja.

2. Projektovanje prozora održavanja

Prozor održavanja nije samo vreme izvršenja komande. On mora obuhvatiti evakuaciju workload-a, preuzimanje i staging paketa, eventualni reboot, ponovno povezivanje, vSAN resync ili storage path stabilizaciju, post-check i vremensku rezervu za rollback. Plan se zasniva na aktuelnim merenjima, ne na optimističnoj proceni. Za rolling rad nad klasterom proverava se da li preostali hostovi mogu da podnesu CPU, memoriju, mrežni i storage teret uz poštovanje HA admission control-a, DRS affinity/anti-affinity pravila, rezervacija, licenci i policy-ja.

• Freeze i konflikt promena: proveriti druge planirane mrežne, storage, backup, PKI i aplikacione aktivnosti; istovremene promene brišu mogućnost pouzdane atribucije uzroka.
• Vlasništvo: odrediti change owner-a, izvršioca, nezavisnog validatora, vlasnika poslovnog servisa i osobu ovlašćenu za go/no-go i rollback odluku.
• Komunikacija: navesti početak, očekivani uticaj, interval statusa, prag kašnjenja i eskalaciju; vremenske oznake voditi u jednoj dogovorenoj zoni.
• Zaštita pristupa: proveriti break-glass nalog, konzolni pristup i iLO/iDRAC ili drugi out-of-band kanal pre promene management mreže ili reboot-a.
• Redosled proizvoda: poštovati Broadcom Interoperability i upgrade-path matrice; vCenter se u podržanom toku uobičajeno nadograđuje pre ESXi hostova, ali ceo stack, uključujući vSAN, NSX, backup i vendor dodatke, mora biti proveren za konkretnu verziju.

3. Pre-check – dokaz da je promena bezbedno započeti

Pre-check nije jedna zelena ikonica. To je skup read-only provera koje potvrđuju početno stanje, preduslove i raspoloživ put oporavka. Rezultat se čuva uz zapis promene sa vremenom, identitetom izvršioca i obimom. Ugrađeni vSphere Lifecycle Manager pre-check i compliance check jesu važni, ali ne proveravaju sve aplikacione i organizacione zavisnosti. U vSphere Automation API-ju izveštaji o poslednjem software pre-check-u postoje za image tok od vSphere 7, dok su izveštaji za desired configuration uvedeni u liniji API-ja 8.0.1; automatizacija zato mora proveriti sposobnosti ciljne verzije, a ne pretpostaviti identične endpoint-e.

Pre-flight kontrolna lista

1. Potvrditi scope, odobrenje, servisne vlasnike i da nema aktivnog P1/P2 incidenta.
2. Proveriti vCenter, ESXi i klaster health, aktivne alarme, nedavne taskove i događaje; nerešen crveni alarm je go/no-go pitanje, a ne dekoracija.
3. Proveriti DRS, HA, EVC i affinity pravila, VM overrides, fault domains i kapacitet posle izdvajanja jednog hosta.
4. Potvrditi da nema VM-ova sa aktivnim instalacionim medijem ili host-local zavisnošću, passthrough/SR-IOV uređajem, fault tolerance stanjem, vGPU ograničenjem ili drugim razlogom koji sprečava vMotion.
5. Proveriti management, vMotion i storage VMkernel mreže, DNS forward/reverse rezoluciju, NTP, MTU, fizičku redundansu i out-of-band pristup.
6. Proveriti datastore kapacitet i latenciju, multipathing, HBA/NIC health, APD/PDL događaje i stanje storage fabric-a.
7. Za vSAN pokrenuti Skyline Health, data migration pre-check, proveru object health/policy compliance, resyncing objects i slobodan kapacitet; odabrati migration mode prema trajanju i toleranciji rizika.
8. Potvrditi kompatibilnost image-a, firmware-a, drajvera, vendor add-on-a, server modela, I/O uređaja i boot uređaja prema aktuelnim matricama.
9. Potvrditi ispravan i obnovljiv backup. Za VCSA patching preporučuje se file-based backup; konzistentan offline snapshot može biti dodatna kratkotrajna tačka povratka kada je podržan, ali nije trajna zamena za backup. Za Enhanced Linked Mode sve članove SSO domena treba tretirati kao konzistentan skup.
10. Zabeležiti baznu liniju: verzije/build brojeve, konfiguraciju, performanse, dostupnost aplikacije, aktivne sesije i sintetički test.

Sledeći PowerCLI primer se izvršava sa administratorske radne stanice povezane na vCenter nalogom koji ima samo potrebne read privilegije. Komande čitaju stanje i prave CSV dokaz; ne menjaju inventar. U produkciji vrednosti za cluster i izlaznu putanju treba parametrizovati i zaštititi od slučajnog prepisivanja.

$clusterName = 'PROD-CL01'
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$outDir = "C:\ChangeEvidence\CHG-2026-0046-$stamp"
New-Item -ItemType Directory -Path $outDir -Force | Out-Null

$cluster = Get-Cluster -Name $clusterName
$hosts = $cluster | Get-VMHost | Sort-Object Name

$hosts | Select-Object Name, ConnectionState, PowerState, Version, Build,
  @{N='CpuUsagePct';E={[math]::Round(100 * $_.CpuUsageMhz / $_.CpuTotalMhz, 1)}},
  @{N='MemoryUsagePct';E={[math]::Round(100 * $_.MemoryUsageGB / $_.MemoryTotalGB, 1)}} |
  Export-Csv "$outDir\hosts.csv" -NoTypeInformation -Encoding UTF8

$cluster | Get-Datastore |
  Select-Object Name, Type, CapacityGB, FreeSpaceGB, State |
  Export-Csv "$outDir\datastores.csv" -NoTypeInformation -Encoding UTF8

Get-AlarmDefinition | Where-Object Enabled |
  Select-Object Name, Description |
  Export-Csv "$outDir\enabled-alarms.csv" -NoTypeInformation -Encoding UTF8

Get-VIEvent -Entity $cluster -Start (Get-Date).AddHours(-24) -MaxSamples 5000 |
  Select-Object CreatedTime, UserName, FullFormattedMessage |
  Export-Csv "$outDir\events-24h.csv" -NoTypeInformation -Encoding UTF8

CSV fajl nije sam po sebi dovoljan: administrator pregleda pragove, upoređuje ih sa SLO-om i označava odstupanja. Formula za odluku o kapacitetu mora uračunati najopterećeniji interval, a ne trenutni prosek:

raspoloživi kapacitet posle izdvajanja hosta
  ≥ vršno zahtevani kapacitet + HA rezerva + operativna sigurnosna margina

Go/no-go vrata

Prelazak u izvršenje odobrava se samo ako su obavezni pre-check-i prošli ili je svako upozorenje eksplicitno prihvaćeno od vlasnika rizika. Primeri za no-go su: neproveren backup; nepostojanje konzolnog pristupa pre management promene; degradiran vSAN objekat; aktivan resync bez procene; nedovoljan N+1 kapacitet; nekompatibilan firmware/driver; nerešena storage path nestabilnost; VM koji se ne može evakuisati, a outage nije odobren; ili istekao sertifikat koji ugrožava ponovno povezivanje.

4. Maintenance mode – tehničko stanje, ne garancija bezbednosti

ESXi host u maintenance mode-u ne izvršava regularne powered-on VM workload-e. vCenter pokušava da evakuiše ili zahteva gašenje VM-ova u zavisnosti od DRS konfiguracije, mogućnosti migracije i načina pokretanja operacije. DRS Fully Automated može premestiti kompatibilne VM-ove; u Manual ili Partially Automated režimu preporuke zahtevaju potvrdu. Powered-off i suspended VM-ovi mogu ostati registrovani na hostu, a servisi poput vSAN-a imaju sopstvena pravila za podatke. Zato se uspeh potvrđuje i stanjem hosta i inventarom workload-a, a ne samo pokrenutim taskom.

vSAN odluka zavisi od storage policy-ja, fault domain-a, slobodnog kapaciteta, trajanja održavanja i stanja objekata. „Ensure Accessibility” nije isto što i „Full Data Migration”: prvo čuva dostupnost, ali može privremeno smanjiti redundansu; drugo pokušava da premesti sve komponente i očuva usklađenost, zbog čega može dugo trajati ili pasti ako nema kapaciteta. Podrazumevani repair delay u mnogim vSAN izdanjima istorijski je 60 minuta, ali stvarnu vrednost i ponašanje treba proveriti u konkretnoj verziji i konfiguraciji umesto oslanjanja na pretpostavku.

GUI i PowerCLI postupak

1. U vSphere Client-u izabrati host, Actions → Maintenance Mode → Enter Maintenance Mode.
2. Pregledati VM i DRS posledice; za vSAN izabrati odgovarajući data migration mode i pokrenuti pre-check.
3. Pratiti Recent Tasks i Events dok host ne dobije stanje Maintenance. Ne započinjati firmware ili reboot dok evakuacija nije potvrđena.
4. Posle održavanja izabrati Exit Maintenance Mode, sačekati Connected stanje, pa izvršiti post-check pre prelaska na naredni host.

Sledeća komanda menja stanje. Izvršava se sa PowerCLI radne stanice tek posle odobrenog go signala. Parametar -Evacuate je smislen uz vCenter i DRS-enabled cluster; ponašanje zavisi od DRS automatizacije i mogućnosti migracije. -Reason ostavlja koristan operativni trag. Za vSAN se eksplicitno zadaje migracioni režim koji je prethodno odobren.

$vmhost = Get-VMHost -Name 'esx01.example.local'

# STATE-CHANGING: ulazak uz evakuaciju i vSAN Ensure Accessibility režim.
$task = Set-VMHost -VMHost $vmhost `
  -State Maintenance `
  -Evacuate `
  -VsanDataMigrationMode EnsureAccessibility `
  -Reason 'CHG-2026-0046 planned patching' `
  -RunAsync

$task | Wait-Task
Get-VMHost -Name $vmhost.Name |
  Select-Object Name, ConnectionState, PowerState

Name                    ConnectionState PowerState
----                    --------------- ----------
esx01.example.local     Maintenance     PoweredOn

Ako klaster nije vSAN, ne prosleđuje se -VsanDataMigrationMode. Ako je DRS Manual/Partially Automated i postoje powered-on VM-ovi, task se pokreće asinhrono, pregledaju se DRS preporuke sa razlogom „Host is entering maintenance mode” i primenjuju tek nakon provere. Nikada ne treba automatizovati slepo prihvatanje svih DRS preporuka iz klastera.

$cluster = Get-Cluster -VMHost $vmhost
$task = Set-VMHost -VMHost $vmhost -State Maintenance -RunAsync `
  -Reason 'CHG-2026-0046 planned maintenance'

Get-DrsRecommendation -Cluster $cluster |
  Where-Object Reason -EQ 'Host is entering maintenance mode' |
  Format-Table Key, Type, Reason -AutoSize

# STATE-CHANGING: primeniti samo pregledane preporuke.
Get-DrsRecommendation -Cluster $cluster |
  Where-Object Reason -EQ 'Host is entering maintenance mode' |
  Apply-DrsRecommendation

$task | Wait-Task

5. Kontrolisano izvršenje i stop-uslovi

Runbook treba da bude sekvenca malih, proverljivih koraka. Posle svakog state-changing koraka sledi očitavanje stanja. Paket se stage-uje pre prozora kada je moguće; checksum i potpis se proveravaju; izvršilac zapisuje početak i kraj; komande se ne menjaju ad hoc bez reprocene rizika. Canary host mora biti reprezentativan, ali ne sme nositi jedinstvenu funkciju. Posle njega sledi observation period dovoljno dug da se pokažu reconnect, driver, storage, vSAN i aplikacioni problemi.

Obavezni stop-uslovi uključuju:

• neočekivani gubitak redundanse ili porast grešaka/latencije iznad dogovorenog praga;
• host se ne vraća u Connected stanje u planiranom vremenu;
• novi PSOD, APD/PDL, NIC/HBA flap, vSAN object inaccessible ili masovni alarm;
• razlika između očekivanog i stvarnog build-a, drajvera ili firmware-a;
• neuspešan kritični sintetički test ili gubitak monitoring vidljivosti;
• istek preostalog vremena potrebnog za bezbedan rollback.

6. Rollback, roll-forward i oporavak

Rollback plan mora postojati pre promene i razlikovati konfiguracioni povratak, softverski rollback, restore iz backup-a i zamenu hardvera. Nije svaka promena reverzibilna. Firmware često nema podržan downgrade; promena šeme ili formata podataka može zahtevati restore; ESXi remediation može promeniti boot bank, ali podržani povratak zavisi od načina instalacije, boot medijuma, verzije i vendor image-a. Kada je uzrok poznat i korekcija manja i bezbednija od povratka, odobrava se roll-forward. Kada je stanje nepoznato ili vreme za oporavak ističe, bira se unapred pripremljen rollback.

Rollback odluka

1. Zaustaviti naredne talase i sačuvati događaje, task ID, tačno vreme i relevantne logove.
2. Odrediti simptom, obim i poslovnu posledicu; ne restartovati nasumično servise pre prikupljanja dokaza.
3. Uporediti nalaz sa unapred definisanim trigger-om i preostalim vremenom.
4. Change owner i ovlašćeni donosilac odluke biraju rollback, roll-forward ili produženje prozora; odluka se zapisuje.
5. Primena rollback-a sledi sopstveni runbook i validaciju; povratak stare verzije nije uspeh dok servis nije testiran.

7. Post-check – dokaz funkcionalnog oporavka

Post-check mora biti ogledalo pre-check-a kako bi poređenje bilo smisleno, ali uključuje i testove koji mogu nastati tek posle promene. „Host je zelen” nije dovoljan kriterijum. Potrebno je potvrditi management plane, data plane i poslovni servis: vCenter taskove i alarme; HA/DRS stanje; vMotion; datastore i multipath; vSAN health, resync i policy compliance; mrežnu redundansu; verzije i build; backup/monitoring integracije; kao i aplikacioni transaction test koji izvršava vlasnik servisa ili automatizovani sintetički monitor.

1. Potvrditi da se host vratio u Connected, da nema novih critical alarma i da su management agenti stabilni.
2. Potvrditi očekivani image/build, drajvere, firmware i compliance; „remediation completed” ne dokazuje nužno pravilnu konačnu verziju.
3. Proveriti sve vmnic/vmk/HBA putanje, datastores i očekivani broj aktivnih/standby path-ova.
4. Za vSAN sačekati ili kontrolisano pratiti resync, object health i policy compliance; ne prelaziti na sledeći host dok je rizik veći od odobrenog.
5. Izvršiti test vMotion-a i, kada je bezbedno, HA/DRS funkcionalni test primeren okruženju.
6. Potvrditi backup, monitoring, syslog, autentikaciju, sertifikate i CMDB/inventory integracije.
7. Uporediti latenciju, error rate, CPU/memory contention i aplikacioni response time sa baznom linijom.
8. Dobiti potvrdu vlasnika servisa, dokumentovati odstupanja i tek tada zatvoriti promenu.

Sledeći PowerCLI primer izlazi iz maintenance mode-a i zato menja stanje. Posle toga read-only provere potvrđuju host i eventualne VM-ove koji su ostali na njemu. Automatski prelazak na naredni host nije dozvoljen samo zato što je cmdlet završio bez izuzetka.

$vmhost = Get-VMHost -Name 'esx01.example.local'

# STATE-CHANGING: izlazak iz maintenance mode-a.
Set-VMHost -VMHost $vmhost -State Connected -Confirm:$false | Out-Null

# READ-ONLY validacija.
$validatedHost = Get-VMHost -Name $vmhost.Name
$residentVms = $validatedHost | Get-VM

[pscustomobject]@{
  Host            = $validatedHost.Name
  ConnectionState = $validatedHost.ConnectionState
  PowerState      = $validatedHost.PowerState
  Version         = $validatedHost.Version
  Build           = $validatedHost.Build
  ResidentVMs     = $residentVms.Count
} | Format-List

8. Logovi, događaji i troubleshooting tokom promene

ESXi shell pristup koristi se samo kada je odobren, vremenski ograničen i auditovan. Sledeće komande su read-only i izvršavaju se kao privilegovani administrator na pogođenom ESXi hostu. Putanja logova je u aktuelnim ESXi izdanjima /var/run/log; filter mora obuhvatiti UTC/lokalno vreme promene i tačan objekat. tail bez korelacije često proizvodi više buke nego dokaza.

# READ-ONLY: stanje maintenance mode-a i instalirani image profil.
esxcli system maintenanceMode get
esxcli software profile get

# READ-ONLY: prostor i poslednje relevantne poruke.
vdf -h
grep -Ei 'error|fail|maintenance|reboot' /var/run/log/hostd.log | tail -n 100
grep -Ei 'error|fail|vib|component' /var/run/log/esxupdate.log | tail -n 100

Dijagnostički tok

Kada host ne ulazi u maintenance mode, najpre se razdvajaju simptom, obim i posledica. Neposredni uzrok može biti VM koji se ne može migrirati, DRS preporuka koja nije primenjena, vSAN policy/capacity pre-check, aktivan resync ili management agent. Osnovni uzrok može biti pogrešno VM/Host pravilo, nedovoljno projektovan kapacitet, local device zavisnost ili neusklađena konfiguracija. Privremeno rešenje može biti odobreno gašenje jedne VM ili izbor Ensure Accessibility; trajna mera je uklanjanje zavisnosti, korekcija policy-ja ili povećanje kapaciteta. Izbor „No Data Migration” samo da bi dugme prošlo nije dijagnostika.

Ako se host posle reboot-a ne poveže, redosled provere je: out-of-band konzola i boot stanje; fizički link; management VMkernel/VLAN/MTU; DNS i vreme; portovi i firewall; hostd/vpxa; prostor na sistemskim particijama; tek zatim restart management agenata ili druge invazivne akcije. Za vLCM timeout, reconnect i ponovni compliance scan mogu pokazati da je instalacija završena, ali se zaključak donosi tek nakon provere build-a i logova. Restart agenata može prekinuti aktivne management operacije i ne izvršava se rutinski bez utvrđene hipoteze.

9. Praktikum – kontrolisano održavanje jednog ESXi hosta

Scenario, topologija i cilj

Laboratorija sadrži vCenter vcsa.lab.example, klaster LAB-CL01 sa najmanje tri ESXi hosta i test VM app-probe01 na shared datastore-u. Opcioni vSAN krak radi se samo ako laboratorija ima zdrav vSAN i dovoljno kapaciteta. Cilj je pripremiti change record, napraviti baznu liniju, evakuisati esx01.lab.example, simulirati bezbednu promenu, validirati povratak i obraditi kontrolisanu grešku.

Potrebni su VCF/VMware PowerCLI, nalog sa minimalnim privilegijama za čitanje i poseban odobren nalog za host maintenance/vMotion, konzolni pristup i direktorijum za dokaze. Rizik je srednji: evakuacija menja smeštaj VM-ova; pogrešan vSAN režim može smanjiti dostupnost. Vežba se ne izvodi na produkciji bez zasebnog odobrenog zapisa promene.

Vežba 1 – plan, bazna linija i go/no-go

1. Otvoriti laboratorijski zapis CHG-LAB-0046: cilj, host, početak/kraj, vlasnik, validator, očekivani outage „nema”, stop-uslov 15 minuta za reconnect i rollback „izaći iz maintenance mode-a; vratiti test VM; ne primenjivati sledeći talas”.
2. U vSphere Client-u pregledati cluster Summary, Monitor → Issues and Alarms, Tasks and Events, DRS i HA. Sačuvati screenshot ili izvoz sa vremenom.
3. Pokrenuti read-only PowerCLI pre-check iz ove lekcije. Potvrditi da je svaki host Connected i da preostala dva hosta imaju dovoljan kapacitet.
4. Proveriti da app-probe01 odgovara na sintetički HTTP/ping test primeren aplikaciji i zabeležiti response time.
5. Ako postoji vSAN, pokrenuti data migration pre-check i potvrditi da nema inaccessible/degraded objekata ni neočekivanog resync-a.

Očekivani rezultat: postoji vremenski označena bazna linija i eksplicitna GO odluka. Ako bilo koji obavezni uslov nije ispunjen, vežba se završava kao ispravan NO-GO; to je uspešna kontrola, ne neuspeh administratora.

Vežba 2 – evakuacija i simulirano održavanje

1. Premestiti app-probe01 na drugi host pomoću vMotion-a i potvrditi da sintetički test nije prekinut.
2. Uvesti esx01.lab.example u maintenance mode GUI-em ili prethodno prikazanim PowerCLI postupkom. Za vSAN koristiti samo režim odobren u Vežbi 1.
3. Potvrditi Maintenance stanje i da nema powered-on VM workload-a na hostu.
4. Kao bezbednu simulaciju promene samo očitati image profil i verziju; ne instalirati VIB i ne menjati firmware.
5. Zabeležiti task ID, početak/kraj i izlaz read-only komandi.

Očekivani rezultat: host je evakuisan i u maintenance mode-u, a aplikaciona sonda ostaje uspešna. Kriterijum završetka nije „task 100%”, već očuvan servis i dokazano stanje hosta.

Vežba 3 – kontrolisana greška i troubleshooting

Bez menjanja infrastrukture napraviti bezbedan negativni test: pokušati da se drugi host uvede u maintenance mode dok laboratorijski kapacitet ili pravilo namerno sprečava migraciju test VM-a, ili postaviti DRS u Manual samo u izolovanoj laboratoriji. Ne primenjivati preporuku automatski.

1. Zabeležiti simptom: maintenance task čeka ili prijavljuje VM koji nije evakuisan.
2. Odrediti obim: jedan host i jedna test VM; posledica: nema produkcionog outage-a.
3. Pregledati Recent Tasks, Events, DRS preporuke i VM/Host pravila; potvrditi hipotezu bez restartovanja servisa.
4. Bezbedna korekcija: ručno pregledati i primeniti samo odgovarajuću DRS preporuku ili vratiti laboratorijski DRS režim.
5. Trajna mera: dopuniti pre-check da proverava automation level i host-affinity/local-device ograničenja.

Kriterijum završetka: neposredni i osnovni uzrok su odvojeno zapisani, korekcija je minimalna, a početna DRS konfiguracija vraćena.

Vežba 4 – izlazak, post-check i rollback drill

1. Izvesti host iz maintenance mode-a i sačekati Connected stanje.
2. Uporediti verziju, build, mrežne i storage putanje, alarme i performanse sa pre-check dokazom.
3. Za vSAN proveriti resync i policy compliance; sačekati dogovoreni nivo zdravlja pre sledećeg hosta.
4. Vratiti app-probe01 samo ako je to deo početnog stanja i potvrditi sintetički test.
5. Simulirati rollback odluku na papiru: ako host ne postane Connected u 15 minuta, navesti ko zaustavlja talas, koje logove čuva, kojim out-of-band putem pristupa i koju proverenu tačku povratka koristi. Ne vršiti stvarni downgrade.
6. Zatvoriti zapis tek kada nezavisni validator potvrdi kriterijume.

Očekivani rezultat: svi objekti su u početnom ili eksplicitno odobrenom konačnom stanju, nema novih alarma, servisni test prolazi i dokazni paket sadrži pre/post podatke, taskove i odluke.

10. Administratorske prakse

• Jedna promena mora imati jednog odgovornog vlasnika, iako je izvršava više timova.
• Pre-check, izvršenje i post-check automatizovati kao idempotentne, verzionisane runbook-ove, ali zadržati ljudska go/no-go vrata za visoki rizik.
• Razdvojiti read-only prikupljanje dokaza od state-changing komandi i koristiti najmanje privilegije.
• Raditi rolling talase sa canary hostom; nikada ne remediate-ovati ceo klaster pre dokazivanja prvog talasa.
• Ne preskakati upozorenje bez vlasnika, obrazloženja i roka za trajnu korekciju.
• Backup smatrati validnim tek kada je restore postupak poznat i periodično testiran.
• Ne koristiti snapshot kao dugotrajni rollback mehanizam niti kao zamenu za aplikaciono konzistentan backup.
• Čuvati task ID, vreme, build, log isečke i rezultate testova; screenshot bez konteksta nije dovoljan audit dokaz.
• Posle neuspešne ili skoro neuspešne promene sprovesti blameless review i pretvoriti nalaz u novu automatsku proveru ili dizajnersku korekciju.

Završna kontrolna tačka

Nakon ove lekcije administrator treba proverljivo da ume da:

• klasifikuje promenu, odredi obim, zavisnosti, blast radius, vlasnike i go/no-go kriterijume;
• izračuna da li klaster zadržava dovoljan kapacitet i dostupnost tokom izdvajanja hosta;
• napravi dokazni pre-check koji obuhvata compute, mrežu, storage, vSAN, kompatibilnost, backup i aplikaciju;
• bezbedno uvede i izvede ESXi host iz maintenance mode-a GUI-em i PowerCLI-jem, uz razumevanje DRS ponašanja;
• izabere i obrazloži vSAN Ensure Accessibility, Full Data Migration ili odbijanje No Data Migration opcije;
• razlikuje rollback, restore i roll-forward i definiše vremenski okidač za odluku;
• koreliše Tasks & Events sa vpxd, hostd, vpxa, esxupdate, vmkernel i vSAN dokazima;
• izvrši post-check koji potvrđuje i infrastrukturni i poslovni servis, a ne samo završetak taska;
• dokumentuje neuspeh kroz simptom, obim, posledicu, neposredni uzrok, osnovni uzrok, workaround i trajnu meru.

Zaključak

Kontrolisana promena je spoj tehničke kompetencije, discipline i odgovornosti. Maintenance mode štiti workload samo ako su evakuacija, kapacitet, storage policy i zavisnosti prethodno razumljivi; backup štiti samo ako je obnovljiv; automatizacija ubrzava rad samo ako proverava preduslove i zaustavlja se na odstupanju. Najvažniji proizvod prozora održavanja zato nije nova verzija, već dokaz da je sistem pre promene bio poznat, da je svaka odluka bila sledljiva, da je oporavak bio moguć i da poslovni servis posle promene ispunjava svoje kriterijume. Takav način rada prirodno priprema administratora za sledeće poglavlje: disaster recovery i orkestrirani oporavak, gde se ista disciplina primenjuje na mnogo širi kvar i strogo definisane RPO/RTO ciljeve.