VMware

Pouzdana vSphere platforma ne nastaje samim instaliranjem najnovijeg paketa. Ona nastaje kada administrator ume da odredi podržano ciljno stanje, dokaže kompatibilnost svih zavisnosti, sprovede promenu kontrolisanim redosledom i potvrdi da su dostupnost, mreža, storage, bezbednost i upravljačke funkcije ostale ispravne. Lifecycle management zato nije povremeno „patchovanje”, već trajni proces upravljanja željenim stanjem infrastrukture.

Ova lekcija se nadovezuje na prethodno izgrađen inventar, monitoring, backup i pripremu platforme za moderna radna opterećenja. Fokus je na instalaciji ESXi-ja i vCenter Server Appliance-a, planiranju nadogradnje i image-based upravljanju ESXi hostovima pomoću vSphere Lifecycle Manager-a (vLCM). Identitet, sertifikati i dublji hardening obrađuju se u narednim lekcijama; ovde ih posmatramo samo kao zavisnosti koje promena verzije ne sme da naruši.

41.1. Ishodi učenja i administratorski model odluke

Po završetku lekcije administrator treba da ume da:

• razlikuje novu instalaciju, patch, update i major upgrade, kao i reinstall od rollback-a;
• odredi podržanu izvornu i ciljnu verziju i pravilan redosled nadogradnje komponenti;
• projektuje ESXi boot, management mrežu, DNS/NTP i storage preduslove pre instalacije;
• sastavi vLCM desired image od base image-a, vendor add-on-a, komponenti i firmware/driver add-on-a;
• razlikuje compliance, remediation pre-check, hardware compatibility i poslovnu validaciju;
• sprovede canary i talasnu remediation proceduru uz kontrolu HA/DRS kapaciteta;
• prikupi događaje i logove, izoluje uzrok neuspeha i izabere bezbedan recovery ili rollback;
• sačuva dokaz o početnom i završnom stanju tako da promena bude ponovljiva i auditabilna.

Zrela odluka prati tok: poslovni razlog → podržani ciljni build → zavisnosti → raspoloživ kapacitet → dokazani recovery → pre-check → ograničeni prvi talas → validacija → širenje promene. Dugme Remediate je tek izvršna faza tog toka.

41.2. Instalacija, patch, update i upgrade nisu ista promena

41.3. Arhitektura lifecycle procesa i granice odgovornosti

vSphere Lifecycle Manager je servis vCenter Server-a koji upravlja sadržajem image-a, izračunava usklađenost i orkestrira pre-check i remediation. ESXi host izvršava instalaciju VIB/component sadržaja i reboot. DRS i vMotion pomažu u evakuaciji workload-a, HA štiti od neočekivanog otkaza, a vendor Hardware Support Manager (HSM), kada je podržan i instaliran, omogućava usklađivanje firmware-a sa drajverima. Nijedna od ovih komponenti ne zamenjuje change plan, backup vCenter-a ili proveru aplikacije.

41.4. Projektovanje i instalacija ESXi hosta

41.4.1. Predinstalaciona kompatibilnost i dizajn

Pre nabavke ili instalacije proveravaju se server model, CPU generacija, BIOS/UEFI, TPM i Secure Boot zahtevi, NIC/HBA/storage kontroleri, boot uređaj, firmware i podržani drajveri. Za OEM platforme prednost obično ima vendor custom image ili odgovarajući vendor add-on, jer generički image može ne sadržati potreban asinhroni drajver ili management provider. OEM image ipak nije trajna dozvola za bilo koju kombinaciju: njegov release, base image i firmware moraju odgovarati ciljnom stanju.

Produkcioni boot dizajn ne treba zasnivati na potrošačkim USB/SD medijima. ESXi 7/8 sistemske particije, persistent scratch, core dump i logovanje zahtevaju pouzdan uređaj i plan zamene. Ako se koristi SAN boot, instalacija mora zaštititi ostale LUN-ove od pogrešnog izbora; zoning i masking pripremaju se tako da je instalateru vidljiv samo nameravani boot LUN kad god je to moguće.

41.4.2. Minimalni infrastrukturni preduslovi

• statička management IP adresa, VLAN, gateway i najmanje dva pouzdana DNS servera;
• forward i reverse DNS zapisi za FQDN pre priključivanja hosta u vCenter;
• NTP izvori dostupni i hostu i VCSA-u; vremenska razlika ugrožava autentikaciju, sertifikate i korelaciju logova;
• redundantne fizičke NIC i storage putanje prema projektovanom modelu;
• out-of-band management (iLO/iDRAC ili ekvivalent), testirana konzola i pravo pristupa;
• zabeležene BIOS, firmware i storage postavke, uključujući virtualizacione ekstenzije i boot mode;
• plan za persistent syslog, scratch i core dump, naročito kod stateless ili nestandardnog boot-a.

41.4.3. Interaktivna instalacija i početna validacija

1. Verifikuj checksum ISO/depot sadržaja i poreklo paketa.
2. Bootuj server kroz kontrolisan out-of-band kanal i potvrdi tačan ciljni disk po modelu, kapacitetu i identifikatoru.
3. Instaliraj ESXi, postavi jedinstvenu root lozinku kroz zaštićeni proces i ukloni instalacioni medij pre reboot-a.
4. U DCUI podesi management NIC/VLAN, IPv4/IPv6 prema standardu, DNS, hostname i test management network.
5. Pristupi Host Client-u preko FQDN-a, podesi NTP i proveri storage/NIC uređaje i sistemske alarme.
6. Dodaj host u odgovarajući datacenter/cluster tek kada njegov build podržava verzija vCenter-a i kada su licence i mrežne zavisnosti spremne.

Sledeće ESXi Shell komande su read-only. Izvršavaju se kao privilegovani administrator preko lokalne konzole ili privremeno omogućenog SSH-a, koji se po završetku zatvara:

vmware -vl
esxcli system version get
esxcli hardware platform get
esxcli network nic list
esxcli storage core adapter list
esxcli storage core path list
esxcli system ntp get

Očekuje se tačan release/build, prepoznat server i sve projektovane NIC, HBA i aktivne storage putanje. Nedostajući uređaj se ne „popravlja” nasumičnim VIB-om: prvo se identifikuju PCI/device ID, HCL zapis, potreban firmware i drajver, pa tek onda bira podržana kombinacija.

41.5. Instalacija i nadogradnja vCenter Server Appliance-a

VCSA instalacija ima dve faze: u prvoj se deploy-uje appliance i podiže privremeni sistem, a u drugoj se konfigurišu SSO domen, vreme i servisi. Kod upgrade-a se deploy-uje novi appliance, zatim se iz izvornog VCSA prenose konfiguracija, inventar, događaji i izabrani istorijski podaci. To nije in-place zamena paketa na postojećoj appliance instanci.

41.5.1. Preduslovi i redosled

• Proveri podržan direktan upgrade path; ako nije podržan, planiraj dokumentovani međukorak.
• Proveri interoperability za ESXi, NSX, SRM/Replication, backup, monitoring, storage plug-in, HSM i druge integracije.
• Uradi file-based backup VCSA-a na podržano odredište i proveri da se backup vidi kao dovršen; image-level backup je dodatna, ne jedina zaštita.
• Potvrdi zdravlje VCSA servisa, dovoljno prostora u svim particijama, DNS/NTP i odsustvo isteklih sertifikata.
• Obezbedi privremenu IP adresu, odgovarajući compute/storage kapacitet i komunikaciju između source i target appliance-a.
• Napravi kompatibilnu verziju distributed switch konfiguracije i razumi da kasniji vDS upgrade može biti nepovratan.

Na VCSA shell-u sledeće komande samo čitaju stanje servisa i prostora:

service-control --status --all
df -h
date -u
timedatectl status

Pre-check nije uspešan ako je neki ključni servis zaustavljen, particija kritično popunjena ili vreme neusaglašeno. Korekcija prostora ili sertifikata predstavlja posebnu promenu i mora se završiti pre upgrade prozora.

41.6. Kompatibilnost kao skup dokaza, a ne jedna zelena oznaka

Ako matrica ne daje jasan rezultat, to nije dozvola za nastavak već otvoren rizik. Potrebno je potvrditi podršku sa vendorom ili izabrati drugi build. „Radilo je u laboratoriji” dokazuje funkcionalnost testirane putanje, ali ne stvara vendor podršku za nepodržanu kombinaciju.

41.7. vSphere Lifecycle Manager: baseline i desired image model

Prelazak klastera sa baseline-a na image upravljanje je promena modela upravljanja i planira se pažljivo; ne tretira se kao kozmetička konverzija. Pre konverzije se proveravaju rešenja koja dodaju VIB-ove, poput mrežnih/storage filtera, NSX-a, backup modula i vendor agenata, jer komponenta koja nije predstavljena u desired image-u može izazvati neusaglašenost ili biti uklonjena tokom remediation-a.

41.8. Anatomija validiranog desired image-a

1. ESXi base image određuje osnovni release i build platforme.
2. Vendor add-on dodaje skup OEM drajvera, agenata i prilagođavanja za serversku platformu.
3. Components dodaju ili menjaju pojedinačne komponente, na primer asinhroni drajver ili rešenje treće strane.
4. Firmware and drivers add-on, preko podržanog HSM-a, povezuje firmware paket sa odgovarajućim drajverima.

Redosled nije proizvoljan. Base image je osnova; vendor add-on i komponente moraju biti kompatibilni s njim. Pre čuvanja image-a vLCM proverava softverske zavisnosti, ali administrator i dalje proverava hardver, interoperabilnost i release notes. Ako dva dodatka nude različite verzije istog paketa, ne bira se „noviji po svaku cenu”, već kombinacija koju podržavaju i VMware/Broadcom i proizvođač hardvera ili integracije.

41.8.1. Online i offline depot

Internet-connected vCenter može sinhronizovati sadržaj iz konfigurisanog depot-a. U izolovanom okruženju administrator preuzima vendor/Broadcom offline bundle kroz odobren kanal, proverava checksum i digitalno poreklo, skenira paket prema politici organizacije, evidentira verziju i uvozi ga u vLCM. Offline bundle se ne raspakuje niti prepravlja ručno. Proxy, DNS, TLS inspekcija i firewall pravila dokumentuju se jer greška sinhronizacije često nije greška image-a već transporta ili poverenja sertifikata.

41.9. Compliance, pre-check, hardware compatibility i remediation

Četiri provere odgovaraju na različita pitanja. Compliance pita da li trenutno instalirani softver odgovara desired image-u. Image validation proverava zavisnosti sastava image-a. Hardware compatibility poredi otkrivene uređaje sa dostupnim HCL podacima. Remediation pre-check traži prepreke izvršenju, kao što su nedovoljan kapacitet, DRS/HA uslovi, aktivne funkcije ili problem sa maintenance mode-om. Tek njihov zajednički rezultat, uz poslovne testove, daje osnovu za promenu.

41.9.1. Produkcioni redosled remediation-a

1. Zamrzni desired image i sačuvaj njegov izvoz, change ID i checksum uvoznog sadržaja.
2. Pokreni compliance, hardware compatibility i remediation pre-check; zatvori sve blokirajuće nalaze.
3. Potvrdi backup VCSA-a, konfiguracije mreže i vendor konfiguracija; potvrdi dostupnost out-of-band konzole.
4. Proveri HA admission control, DRS pravila, vSAN resync i storage putanje; ne počinji uz degradirano stanje.
5. Izaberi canary host reprezentativnog hardvera, migriraj/ugasi VM-ove i uvedi ga u maintenance mode.
6. Remediate jedan host, sačekaj reboot, reconnect i završetak post-boot servisa.
7. Izvrši tehnički i workload post-check; posmatraj stabilizacioni period.
8. Nastavi talasno, uz ograničenu paralelizaciju samo ako klaster, vSAN politika i poslovni rizik to dopuštaju.
9. Na kraju ponovi compliance i health provere, dokumentuj izuzetke i zatvori change tek posle poslovne potvrde.

41.10. Automatizacija i dokazivo stanje pomoću PowerCLI-ja

Sledeći primer koristi aktuelne LCM cmdlet-e. Izvršava se sa administratorske radne stanice u PowerShell-u sa instaliranim VCF PowerCLI modulima. Prvi deo je read-only; izvozi dokaz željenog stanja i pokreće provere. Naziv klastera i putanja moraju se prilagoditi okruženju.

Connect-VIServer -Server 'vcsa01.example.rs'

$cluster = Get-Cluster -Name 'PROD-CL01'

# Read-only provere i izvoz dokaza
Test-LcmClusterHealth -Cluster $cluster
Test-LcmClusterCompliance -Cluster $cluster
Get-LcmHardwareCompatibility -Cluster $cluster
Export-LcmClusterDesiredState `
  -Cluster $cluster `
  -Destination 'C:\Change\CHG-0041\PROD-CL01-desired-state.json'

# Inventarski dokaz pre promene
Get-VMHost -Location $cluster |
  Select-Object Name, Version, Build, ConnectionState, PowerState |
  Export-Csv 'C:\Change\CHG-0041\hosts-before.csv' -NoTypeInformation

Očekivani rezultat je uspešno kreiran desired-state JSON, inventarski CSV i eksplicitni health/compliance rezultati. Cmdlet izlaz mora se pregledati; odsustvo PowerShell exception-a nije isto što i prolaz svih provera. Datoteke mogu sadržati osetljive inventarske podatke i čuvaju se u kontrolisanom change repozitorijumu.

Uvoz desired state-a je state-changing: menja deklarisano ciljno stanje klastera, ali sam po sebi ne treba poistovetiti sa remediation-om hostova. Koristi se tek posle peer review-a specifikacije i u kontrolisanom prozoru:

$cluster = Get-Cluster -Name 'LAB-CL01'

Import-LcmClusterDesiredState `
  -Cluster $cluster `
  -LocalSpecLocation 'C:\Change\CHG-0041\approved-lab-image.json'

Test-LcmClusterCompliance -Cluster $cluster

Bezbedan rollback ove konfiguracione promene je ponovni uvoz prethodno izvezenog i odobrenog desired-state fajla, pod uslovom da je i dalje dostupan odgovarajući depot sadržaj. To ne vraća automatski već remediate-ovan ESXi host; njegov recovery je poseban postupak.

41.11. Dostupnost, performanse, bezbednost i oporavak tokom promene

41.11.1. Dostupnost i kapacitet

Maintenance jednog hosta smanjuje N+1 rezervu. Ako preostali hostovi nemaju CPU, memoriju, mrežni ili storage kapacitet, DRS neće moći bezbedno da evakuiše workload. Affinity/anti-affinity pravila, passthrough uređaji, lokalni diskovi, FT, pinned workload-i i VM-ovi bez podržanog vMotion-a moraju biti poznati pre promene. Privremeno isključivanje HA admission control-a samo da bi remediation prošao uklanja zaštitnu ogradu i zahteva zasebnu analizu i odobrenje; nije standardna korekcija.

41.11.2. Bezbednost lanca snabdevanja

Image sadržaj dolazi samo iz zvaničnog ili odobrenog vendor izvora. Čuvaju se naziv paketa, verzija, vreme preuzimanja i checksum. Administrativni nalozi koriste najmanje potrebne privilegije, a privremeni SSH/ESXi Shell se po završetku gasi. Promene BIOS-a, Secure Boot-a, TPM-a ili acceptance level-a ne uvode se usput radi „prolaska” upgrade-a; one imaju zaseban bezbednosni uticaj i obrađuju se kao kontrolisane promene.

41.11.3. Recovery nije isto što i rollback

VCSA file-based restore vraća appliance iz backup-a kroz installer odgovarajuće verzije. ESXi može u određenim uslovima da se vrati na prethodni bootbank izbor preko DCUI kombinacije Shift+R, ali rollback nije dostupan posle svake vrste instalacije/promene i zavisi od očuvanog prethodnog image-a. Kod nepodržanog ili neuspešnog rollback-a plan je reinstall podržanog image-a, vraćanje host konfiguracije kroz dokumentovani postupak i ponovno priključenje workload-u. VM podaci na shared datastore-u ne smeju zavisiti od ESXi boot diska.

Nadogradnja vDS verzije, virtual hardware-a ili pojedinih firmware-a može biti nepovratna ili zahtevati vendor postupak. Zato se te promene odvajaju od osnovnog ESXi talasa i odlažu dok nova platforma ne prođe stabilizacioni period.

41.12. Posmatranje, logovi i korelacija dokaza

Logovi se filtriraju u uskom vremenskom intervalu oko Task/Event zapisa i po hostname-u ili task ID-u. Sledeće komande su read-only; izvršavaju se na odgovarajućem VCSA/ESXi shell-u sa privilegovanim nalogom. Vremenski opseg prilagodi incidentu:

# VCSA: poslednje vLCM greške
grep -Ei 'error|fail|timeout|reset|metadata' \
  /var/log/vmware/vmware-updatemgr/vmware-vum-server.log | tail -n 100

# ESXi: greške instalacije image-a i zavisnosti
grep -Ei 'error|fail|dependency|signature|space' \
  /var/run/log/esxupdate.log | tail -n 100

# ESXi: poslednje kernel poruke o uređajima i putanjama
grep -Ei 'nmp|apd|pdl|reset|link.*down|failed' \
  /var/run/log/vmkernel.log | tail -n 100

Jedna reč error nije dovoljan zaključak. Nalaz se povezuje sa vCenter task-om, tačnim hostom, vremenom, mrežnim događajem, hardware health-om i poslednjom promenom. Pre brisanja depot sadržaja, restartovanja servisa ili ponavljanja remediation-a pravi se support bundle i čuva početno stanje.

41.13. Tipični kvarovi i sistematičan troubleshooting

41.13.1. Incident tok

1. Zaustavi širenje: pauziraj sledeći remediation talas; ne menjaj desired image dok se dokaz ne sačuva.
2. Odredi simptom, obim i posledicu: jedan host ili svi, scan ili boot, management ili workload, degradacija ili outage.
3. Prikupi dokaze: Tasks/Events, build pre/posle, vLCM i ESXi logove, hardware health, mrežu i storage putanje.
4. Postavi i testiraj hipotezu: transport, metadata, dependency, kapacitet ili hardver; počni read-only proverama.
5. Primeni zaobilazno rešenje: zadrži host van produkcije, vrati workload na zdrave hostove ili produži maintenance prozor.
6. Trajno ispravi uzrok: podržani image, firmware/driver, repository, kapacitet ili vendor korekcija.
7. Validiraj oporavak: compliance, health, mreža/storage, test VM i monitoring bez novih alarma.
8. Dokumentuj RCA: razdvoji neposredni uzrok, osnovni uzrok, doprinosne faktore i preventivnu kontrolu.

41.14. Praktikum: od kompatibilnosti do validiranog image-a

Vežba 1 – Izrada matrice kompatibilnosti i change paketa

Cilj i kontekst: odobriti prelazak LAB klastera sa poznatog izvornog build-a na ciljni vSphere 8.x build bez oslanjanja na pretpostavke.

Topologija: jedan VCSA, klaster LAB-CL01, dva ESXi hosta, shared datastore, management/vMotion mreže i najmanje jedna test VM.

Preduslovi i rizik: read-only vCenter pristup za inventar, pristup zvaničnim matricama i release notes; rizik je nizak jer se stanje još ne menja.

1. Zabeleži verziju/build VCSA-a i oba hosta, server model, CPU, NIC/HBA device ID, driver i firmware.
2. Proveri upgrade path i redosled vCenter → ESXi.
3. Proveri server i I/O uređaje u Compatibility Guide-u za ciljni release.
4. Proveri interoperabilnost backup-a, storage plug-in-a i drugih laboratorijskih integracija.
5. Pročitaj release notes: poznati problemi, uklonjeni drajveri, posebni pre/post-upgrade koraci i zahtevan reboot.
6. Napravi tabelu odluke: prolazi / blokira / uslovno / vlasnik / dokaz.

Očekivani rezultat i validacija: change paket sadrži tačan ciljni build, sve kompatibilne kombinacije, otvorene rizike, maintenance procenu i rollback/recovery put. Vežba je završena samo ako nema neadresiranog blokirajućeg polja.

Vežba 2 – Kreiranje i izvoz LAB desired image-a

Cilj: napraviti image koji predstavlja podržano i ponovljivo stanje klastera.

Privilegije i alati: vSphere Client i nalog sa Lifecycle Manager privilegijama; PowerCLI za read-only izvoz. Rizik je srednji jer promena desired image-a menja cilj klastera, ali još ne menja hostove.

1. U vSphere Client-u otvori Hosts and Clusters → LAB-CL01 → Updates → Image.
2. Ako je klaster baseline-managed, pregledaj pre-conversion izveštaj i evidentiraj rešenja koja dodaju VIB-ove; konverziju radi samo ako laboratorijska verzija i integracije to podržavaju.
3. Izaberi odobren ESXi base image, odgovarajući vendor add-on i samo opravdane komponente.
4. Pokreni image validation. Ne čuvaj image dok postoji dependency konflikt.
5. Sačuvaj image, pokreni hardware compatibility i compliance.
6. Izvezi desired state PowerCLI cmdlet-om iz odeljka 41.10 i sačuvaj ga uz change paket.

Očekivani rezultat: image je validan, oba hosta imaju objašnjiv compliance status, a hardware nalaz nema neadresirani incompatibility.

Rollback: pre izmene izvezi prethodni desired state. Ako je novi image pogrešan i nijedan host nije remediate-ovan, vrati prethodnu specifikaciju i ponovi compliance. Ako je host već promenjen, zaustavi vežbu i primeni recovery plan iz Vežbe 4.

Vežba 3 – Canary remediation jednog hosta

Cilj: bezbedno primeniti image na prvom hostu i dokazati funkcionalnost pre drugog talasa.

Preduslovi: zdrav klaster, nema vSAN resync-a, testiran vMotion, dovoljno kapaciteta na drugom hostu, VCSA backup, OOB konzola i odobren maintenance prozor. Rizik je visok jer host ulazi u maintenance mode i rebootuje se.

1. Izvezi inventar pre promene i zabeleži aktivne alarme, build, NIC/storage putanje i test VM stanje.
2. Pokreni remediation pre-check. Svako upozorenje klasifikuj kao blokirajuće, prihvaćeno ili za korekciju.
3. Migriraj test VM i ostale workload-e sa esx-lab01; potvrdi da host nema aktivnih VM-ova koje ne sme izgubiti.
4. Uvedi host u maintenance mode. Ako ne uspe, ne forsiraj; analiziraj DRS, VM i storage događaje.
5. U kartici Updates → Image pokreni remediation samo za canary host.
6. Prati Tasks/Events i OOB konzolu kroz instalaciju i reboot.
7. Posle reconnect-a proveri build, compliance, NIC linkove, VMkernel ping/vMotion, datastore putanje, NTP i hardware health.
8. Izađi iz maintenance mode-a, vrati test VM i izvrši aplikacioni smoke test.
9. Posmatraj monitoring najmanje jedan dogovoreni stabilizacioni interval pre drugog hosta.

Kriterijum završetka: canary host je compliant; nema novih critical alarma; redundantne mrežne/storage putanje su aktivne; test VM uspešno radi i može da se migrira; dokaz je sačuvan.

Vežba 4 – Dijagnostika kontrolisanog neuspeha i recovery odluka

Cilj: vežbati incident response bez kvarenja hosta. Simptom je simuliran: „host ne može u maintenance mode jer test VM ima lokalno vezan ISO ili nepodržanu migracionu zavisnost”.

1. Na test VM bez poslovnih podataka poveži ISO sa lokalnog host datastore-a ili napravi drugu reverzibilnu laboratorijsku prepreku.
2. Pokreni samo pre-check ili pokušaj kontrolisani ulazak u maintenance mode; ne pokreći remediation.
3. Zabeleži simptom, obim i posledicu: jedan host, pre-remediation faza, bez outage-a.
4. Pregledaj Tasks/Events, VM uređaje i DRS preporuke; potvrdi vezu između prepreke i konkretnog VM-a.
5. Bezbedna korekcija je odvajanje laboratorijskog ISO-a ili promena na shared sadržaj, zatim ponovljeni vMotion/pre-check.
6. Potvrdi da host može u maintenance mode, zatim ga vrati u početno stanje bez remediation-a.
7. Napiši kratki RCA: neposredni uzrok je lokalna zavisnost; osnovni uzrok je nedovoljna pre-change provera VM uređaja; preventivna mera je automatizovani inventarski check.

Recovery grana za stvarni boot kvar: ostavi host izolovan od workload-a, prikupi OOB/boot i esxupdate.log dokaze, proveri podržanost Shift+R rollback-a, a ako nije primenljiv izvrši reinstall odobrenog image-a i povrat konfiguracije. Ne vraćaj host u klaster dok mreža, storage, time sync, compliance i test VM nisu potvrđeni.

Vežba 5 – Završna validacija i audit paket

Cilj: dokazati ne samo da je zadatak završen, već da platforma radi u očekivanom stanju.

1. Ponovi health, compliance i hardware compatibility provere.
2. Izvezi inventar hostova posle promene i uporedi verziju/build sa početnim CSV-om.
3. Proveri HA/DRS, vMotion, management redundansu, sve datastore-ove i multipathing.
4. Pregledaj alarme, Tasks/Events i centralni syslog za ceo maintenance interval.
5. Pokreni smoke test reprezentativne VM aplikacije i potvrdi backup/monitoring integraciju.
6. Sačuvaj desired-state JSON, pre/post inventar, compatibility dokaze, izuzetke, vreme i imena odobravalaca.
7. Vrati privremeno promenjene DRS/operativne postavke i ugasi privremeni SSH.

Kriterijum završetka: nema neobjašnjivog drift-a ni novog kritičnog alarma, svi hostovi su na odobrenom buildu, poslovni vlasnik je potvrdio servis, a change zapis sadrži ponovljive dokaze.

41.15. Administratorske prakse

• Standardizuj mali broj odobrenih image varijanti prema hardverskim porodicama, umesto jednog univerzalnog image-a za nepovezane platforme.
• Odvoji izbor ciljnog build-a od izvršenja: image prolazi peer review pre remediation-a.
• Prvo testiraj u laboratoriji, zatim na canary hostu, pa u ograničenim talasima; stabilizacioni period je deo promene.
• Ne mešaj ESXi, firmware, vDS, VMware Tools i virtual hardware promene u jedan nedeljiv korak.
• Pre svake state-changing akcije sačuvaj inventar, desired state, alarme i plan oporavka.
• Ne ignoriši warning zato što nije crven: dokumentuj vlasnika, procenu posledice i odluku.
• Održavaj OOB pristup, VCSA file-based backup i proverljiv reinstall postupak; snapshot nije zamena za backup.
• Automatizuj prikupljanje dokaza i compliance, ali zahtevaj kontrolu za promenu desired image-a i remediation.
• Posle incidenta popravi procesnu kontrolu koja je dozvolila uzrok, ne samo konkretni host.

41.16. Završna kontrolna tačka

Lekcija je savladana kada možeš da dokažeš da umeš da:

• navedeš tačan izvorni i ciljni release/build i podržan upgrade path;
• objasniš zašto se vCenter nadograđuje pre ESXi hostova;
• napraviš compatibility matricu za server, I/O uređaje, firmware, drajvere i integracije;
• objasniš sastav desired image-a i opravdaš svaki dodatak;
• razlikuješ image validation, compliance, hardware compatibility i remediation pre-check;
• izračunaš da li klaster zadržava potreban kapacitet i dostupnost tokom maintenance-a;
• izvezeš desired state i pre/post inventar bez promene hostova;
• sprovedeš canary remediation i validiraš mrežu, storage, HA/DRS i test workload;
• iz logova povežeš prvi neuspešan korak sa neposrednim i osnovnim uzrokom;
• razlikuješ rollback od recovery-ja i izabereš ostvariv plan za VCSA i ESXi;
• zatvoriš change tek kada postoji tehnički, poslovni i audit dokaz.

Zaključak

Instalacija i nadogradnja vSphere infrastrukture jesu tehničke operacije, ali njihov kvalitet određuju priprema i dokazi. vSphere Lifecycle Manager omogućava da klaster dobije deklarisano i proverljivo željeno stanje, no ne ukida odgovornost administratora da proveri upgrade path, hardver, firmware, drajvere, integracije, kapacitet i recovery. Zelen compliance status potvrđuje samo jedan sloj istine; pouzdana promena postoji tek kada platforma i workload prođu merljive post-check provere.

Najbezbedniji lifecycle proces je konzervativan u obimu, precizan u redosledu i bogat dokazima: vCenter pre hostova, validiran image pre remediation-a, canary pre talasa i stabilizacija pre zatvaranja promene. Takav pristup priprema administratora za naredne teme — identitet, sertifikate i naprednu zaštitu — jer bez kontrolisanog lifecycle-a ni bezbednosna konfiguracija ne može ostati pouzdana kroz vreme.