VMware

Stabilno vSphere okruženje ne nastaje tako što administrator povremeno proveri koliko je slobodnog prostora ostalo. Planiranje kapaciteta je upravljački proces kojim se potražnja workload-a, fizički resursi, politike dostupnosti, ograničenja proizvoda i vreme nabavke prevode u odluke koje mogu da se provere. Njegov cilj nije najveća moguća konsolidacija, već dovoljno resursa da infrastruktura podnese očekivani rast, vršno opterećenje, kvar i planirano održavanje bez nekontrolisanog pada kvaliteta usluge.

Lekcija se nadovezuje na monitoring i analizu performansi iz lekcija 34 i 37, na HA i DRS iz lekcija 32 i 33, kao i na bezbednu automatizaciju iz lekcije 44. Ovde njihove metrike i inventarski podaci postaju model kapaciteta. Rezultat nije samo grafikon, već dokumentovana odluka: koji resurs je ograničavajući, kada će prag biti dostignut, šta treba proširiti, koliko rezerve mora ostati i kojim dokazom se potvrđuje da plan radi. Takav model je neposredan preduslov za kontrolisanu promenu i održavanje u narednoj lekciji.

1. Kapacitet nije isto što i trenutno slobodan resurs

Fizički kapacitet je instalirana količina resursa: procesorska snaga, memorija, storage, mrežni interfejsi i portovi. Efektivni kapacitet uzima u obzir arhitekturu i politike — na primer rezervu za ESXi, HA failover, vSAN zaštitu podataka ili storage RAID. Upotrebljivi kapacitet je deo efektivnog kapaciteta koji organizacija dozvoljava workload-ima da potroše pre internog upozorenja. Preostali kapacitet je razlika između upotrebljivog kapaciteta i merene ili projektovane potražnje.

Fizički kapacitet
− sistemski overhead i arhitektonska zaštita
− rezerva za kvar i održavanje
− operativni sigurnosni prag
= upotrebljivi kapacitet

Upotrebljivi kapacitet − projektovana potražnja = preostali kapacitet

„Slobodno sada” opisuje samo jedan trenutak. Kapacitet za odluku mora da obuhvati reprezentativan period, sezonske i poslovne vrhove, rast, kvar najveće relevantne jedinice i vremenski razmak od odobrenja do stavljanja nove opreme u rad. Zbog toga se prosečna iskorišćenost nikada ne koristi sama: prosek može sakriti kratke, ali poslovno kritične vrhove, neuravnotežen host, zasićen datastore ili VM sa dugim CPU Ready vremenom.

2. Poslovni zahtev, SLO i jedinica planiranja

Model počinje zahtevom, ne metrikom. Administrator mora da zna koje usluge su kritične, njihov radni kalendar, očekivani rast, period zadržavanja podataka, RPO/RTO, dozvoljeno vreme degradacije i koje operacije moraju moći da se izvrše u vrhu opterećenja. Dve infrastrukture sa istim brojem VM-ova mogu zahtevati potpuno različit kapacitet ako jedna mora preživeti gubitak hosta bez degradacije, a druga prihvata kratkotrajno smanjenje performansi.

Jedinicu planiranja odredi prema failure domain-u i mestu na kojem se donosi odluka. CPU i memorija se najčešće planiraju na nivou klastera, ali se proverava i svaki host. Storage se analizira po datastore-u, datastore cluster-u, vSAN klasteru, storage pool-u i backend kontroleru. Mreža se meri po pNIC-u, uplink timu, vmnic-u, vmkernel servisu, port grupi i fizičkom putu. vCenter i druge management komponente imaju zasebne inventarske, sesijske i operativne granice.

• Horizont podataka: najmanje jedan pun poslovni ciklus; za sezonske sisteme uključiti relevantnu sezonu i prethodnu godinu kada je dostupna.
• Granularnost: dovoljno fina da se vide vrhovi, ali uz istorijske rollup intervale koji omogućavaju dug trend.
• Percentili: p95 ili p99 pomažu da se odvoje tipična visoka opterećenja od pojedinačnih anomalija; kritični batch prozor se ipak ocenjuje posebno.
• Scenariji: normalan rad, poslovni vrh, N−1 kvar, planirani maintenance, oporavak i paralelne administrativne operacije.
• Lead time: prag za akciju mora biti dostignut pre nego što nabavka, isporuka, instalacija i validacija postanu kritični put.

3. CPU kapacitet: potražnja, contention i oblik workload-a

Sabiranje GHz nije dovoljno. Procesorske generacije imaju različite performanse po jezgru, NUMA topologija utiče na široke VM-ove, a overcommit menja odnos dodeljenog vCPU-a i fizičkih jezgara. Posmatraj istovremeno host/cluster utilization i demand, VM CPU usage, CPU Ready, Co-Stop kod SMP VM-ova, limit i reservation, kao i frekvenciju i trajanje vrhova. Visok Ready uz umerenu prosečnu iskorišćenost može ukazivati na prevelike VM-ove, neuravnotežen klaster, affinity ograničenje ili vremenski sinhronizovan batch.

Odnos vCPU:pCPU je inventarska mera konsolidacije, ne dokaz da CPU ima dovoljno. Prihvatljiv odnos zavisi od profila workload-a, SLO-a, generacije procesora i kontencije. Ne postoji univerzalna bezbedna vrednost. Rightsizing vCPU-a se radi tek kada metrički dokazi pokažu da VM ne koristi dodeljenu širinu i kada aplikacioni vlasnik potvrdi prihvatljiv rizik; samo nizak prosek nije dovoljan.

4. Memorija: aktivna potražnja, rezervacije i cena pritiska

Provisioned memory pokazuje koliko je memorije konfigurisano VM-ovima, consumed koliko fizičkih stranica trenutno zauzimaju, a active procenjuje nedavno aktivno korišćene stranice. Nijedna od ovih metrika sama nije dovoljan model. Za bezbedan plan koreliši host i VM memory usage sa ballooning-om, compression-om, host swapping-om, VM swap-in/swap-out aktivnošću, reservations, limits i guest OS pokazateljima. Guest cache može izgledati kao visoka potrošnja, dok nizak active ne opravdava automatsko smanjenje memorije bez razumevanja workload-a.

Rezervacije utiču na admission i mogućnost uključivanja ili migracije VM-a: ne troše se kao običan prosek, ali moraju biti raspoložive. Kada počne host swapping, problem više nije samo „visoka iskorišćenost”; latencija može pogoditi aplikacije i produžiti vMotion ili maintenance. Plan zato mora da pokaže da se kritične VM rezervacije i overhead mogu zadovoljiti i posle predviđenog kvara.

5. Storage: prostor, performanse i zaštita podataka

Storage ima najmanje dve odvojene dimenzije: kapacitet u bajtovima i servisni kapacitet u IOPS/throughput/latency. Datastore sa mnogo slobodnog prostora može biti zasićen I/O zahtevima, dok datastore sa malim slobodnim prostorom može trenutno imati nisku latenciju, ali visok rizik od prekida pri rastu thin diskova, snapshot-a ili backup operacije. Zato se prate used/provisioned/uncommitted prostor, stopa rasta, read/write IOPS, throughput, uređajna i kernel latencija, queue pokazatelji, greške i stanje svih putanja.

Kod vSAN-a rezultat zavisi od storage policy-ja, zaštitne šeme, fault domain-a, slack/operations rezerve, deduplikacije ili kompresije gde su dostupne, kao i od prostora potrebnog za resynchronization i maintenance mode. Ne koristi prost zbir kapaciteta uređaja kao upotrebljiv prostor. Pre ulaska hosta u maintenance mode koristi odgovarajući pre-check/report i proceni uticaj izabrane data migration opcije.

6. Mrežni kapacitet i zajednički putevi

Mrežni plan obuhvata propusni opseg, packet rate, latenciju, gubitke, greške, drops i burst karakteristike. Proveri svaki smer i svaki zajednički put: VM saobraćaj, management, vMotion, vSAN ili IP storage, backup i replikaciju. Dva 25 Gb/s uplinka nisu automatski 50 Gb/s za jedan tok; rezultat zavisi od teaming politike, broja tokova, hashing-a, fizičkih switch-eva i protokola. Plan mora da razmotri i gubitak jednog uplinka ili switch-a.

Posebno modeluj operacije koje stvaraju kratkotrajno veliko opterećenje: paralelni vMotion, backup, restore, vSAN resync, replikaciju i masovno patchovanje. Ako se svi servisi oslanjaju na isti fizički put, njihov zbirni vrh je važniji od proseka svakog servisa pojedinačno.

7. Dostupnost: N+1, maintenance i ograničavajući host

N+1 ne znači samo „imamo jedan host više”. Klaster mora posle gubitka relevantnog hosta imati dovoljno CPU-a, memorije, mrežne i storage dostupnosti da zadovolji politike i prihvatljiv nivo performansi. U heterogenom klasteru gubitak najvećeg hosta može biti stroži scenario od prosečnog hosta. Ako affinity/anti-affinity pravila, licence, GPU uređaji, NUMA zahtevi ili posebna konektivnost ograničavaju smeštaj, zbirni slobodan kapacitet može biti neupotrebljiv za konkretan VM.

Primer modela, ne proizvodni limit:
6 hostova × 512 GiB = 3.072 GiB fizičke memorije
rezerva za najveći host (N−1) = 512 GiB
ESXi/servisni overhead i interna rezerva = 240 GiB
upotrebljivi kapacitet = 2.320 GiB
projektovana vršna potražnja = 2.050 GiB
headroom = 270 GiB, odnosno 11,6% upotrebljivog kapaciteta

Ovaj rezultat nije automatsko odobrenje: mora se proveriti da li preostalih pet hostova pojedinačno može prihvatiti evakuisane VM-ove, da li rezervacije mogu biti zadovoljene i da li storage i mreža podnose migraciju i novi raspored. HA Admission Control je zaštitni mehanizam, ali njegov procenat ili slot politika nisu zamena za performansni model. DRS može poboljšati raspored samo ako postoji dozvoljen i kompatibilan cilj sa stvarnim resursima.

8. Configuration Maximums: podržana granica i verzijski dokaz

Zvanični Configuration Maximums alat ili dokument koristi se za tačnu verziju proizvoda i komponentu: ESXi host, virtuelnu mašinu, vCenter Server, klaster, mrežu, storage, vSAN i druge funkcije. Pre poređenja zabeleži edition/licencu, build i update nivo, topologiju i zavisne proizvode. Ako je mešovita verzija privremeno podržana tokom nadogradnje, planiraj prema najrestriktivnijem primenljivom skupu dok se stanje ne homogenizuje.

1. Identifikuj tačnu verziju i build svakog vCenter/ESXi sistema i komponentu čiji se limit proverava.
2. Otvori aktuelni zvanični Configuration Maximums prikaz za tu verziju; ne koristi memorisanu vrednost ili rezultat za drugu verziju.
3. Pročitaj fusnote, preduslove, izuzetke i zajedničke limite. Pojedinačne granice se ne mogu uvek istovremeno dostići.
4. Uporedi trenutno stanje, planirano stanje posle rasta i stanje tokom maintenance/DR scenarija.
5. U evidenciji navedi naziv metrike/objekta, trenutnu i projektovanu vrednost, limit, iskorišćenost limita, verziju izvora i datum provere.
6. Postavi interni prag dovoljno niže da tim može da reaguje pre podržane granice i pre degradacije operacija.

9. Bazna linija, trend i prognoza

Bazna linija opisuje normalno ponašanje za poznat poslovni period. Beleži medijanu, p95/p99, vrh, trajanje vrha, radni kalendar i događaje koji objašnjavaju odstupanja. Kapacitet se prognozira po resursu, a datum akcije određuje najraniji ograničavajući resurs. Jednostavna linearna stopa rasta može biti početni model, ali se ne primenjuje na sezonsku, stepenastu ili projektno vođenu potražnju bez korekcije.

Mesečna stopa rasta = (potrošnja na kraju − potrošnja na početku) / broj meseci
Meseci do internog praga = (prag − trenutna potrošnja) / mesečna stopa rasta
Datum odluke = procenjeni datum praga − nabavni i implementacioni lead time

Prognoza treba da ima najmanje osnovni, očekivani i stresni scenario. Uključi poznate projekte, migracije, retention promene i planirani decommission. Aria Operations, kada je licenciran i uveden, može izračunavati usable capacity, capacity remaining i time remaining prema politici i prognozi; rezultat zavisi od izabrane politike, praga, istorije i kvaliteta podataka. On je pomoć u odlučivanju, a ne zamena za proveru failure scenarija i Configuration Maximums.

10. Prikupljanje dokaza u vSphere Client-u i VCF PowerCLI-ju

U vSphere Client-u koristi Monitor > Performance > Advanced na nivou klastera, hosta, VM-a i datastore-a, prilagodi brojače i vremenski opseg, zatim koreliši sa Tasks and Events, alarmima i poznatim promenama. Istorijska dostupnost i granularnost zavise od Statistics Level-a i retention intervala vCenter-a; podizanje nivoa statistike povećava obim baze i mora biti planska promena. Za precizne nazive brojača proveri Get-StatType, jer dostupnost zavisi od objekta, verzije i nivoa statistike.

Sledeći PowerCLI primeri su read-only. Izvršavaju se sa administratorske radne stanice nad vCenter-om, nalogom koji ima najmanje privilegije za čitanje inventara i performansi. Sertifikat mora biti validiran prema politici iz lekcije 42; trajno ignorisanje nevažećih sertifikata nije prihvatljiva produkciona praksa.

# VCF PowerCLI / VMware.VimAutomation.Core
Connect-VIServer -Server 'vcsa01.example.test'

# Inventar verzija i build-ova; osnova za izbor Configuration Maximums skupa.
Get-VMHost | Select-Object Name, Version, Build, ConnectionState |
  Sort-Object Name

# Brzi pregled fizičkog CPU/memory kapaciteta i trenutne potrošnje.
Get-Cluster -Name 'PROD-CL01' | Get-VMHost |
  Select-Object Name, ConnectionState,
    @{N='CpuTotalGHz';E={[math]::Round($_.CpuTotalMhz / 1000, 1)}},
    @{N='CpuUsageGHz';E={[math]::Round($_.CpuUsageMhz / 1000, 1)}},
    @{N='MemoryTotalGiB';E={[math]::Round($_.MemoryTotalGB, 1)}},
    @{N='MemoryUsageGiB';E={[math]::Round($_.MemoryUsageGB, 1)}}

Ovaj snapshot nije prognoza. Za reprezentativan interval prikupi statistiku i agregiraj je po vremenu i objektu. Veliki Get-Stat upiti mogu opteretiti vCenter i vratiti mnogo podataka; prvo ograniči entitet, brojače i interval, a produkcioni izvoz zakazuj van vrha i testiraj na manjem uzorku.

$cluster = Get-Cluster -Name 'PROD-CL01'
$start   = (Get-Date).AddDays(-7)
$metrics = @(
  'cpu.usage.average',
  'cpu.ready.summation',
  'mem.usage.average',
  'mem.swapinRate.average',
  'mem.swapoutRate.average'
)

# Read-only upit. Najpre proveriti dostupne brojače za objekat.
$available = Get-StatType -Entity ($cluster | Get-VMHost | Select-Object -First 1)
$metrics | Where-Object { $_ -notin $available } |
  ForEach-Object { Write-Warning "Brojač nije dostupan: $_" }

$stats = Get-Stat -Entity ($cluster | Get-VMHost) `
  -Stat $metrics -Start $start -ErrorAction Stop

$stats |
  Group-Object Entity, MetricId |
  ForEach-Object {
    $values = $_.Group.Value | Sort-Object
    $p95Index = [math]::Ceiling($values.Count * 0.95) - 1
    [pscustomobject]@{
      Series = $_.Name
      Samples = $values.Count
      Average = [math]::Round(($values | Measure-Object -Average).Average, 2)
      P95 = [math]::Round($values[[math]::Max(0, $p95Index)], 2)
      Maximum = [math]::Round(($values | Measure-Object -Maximum).Maximum, 2)
    }
  } | Sort-Object Series

# Read-only pregled datastore kapaciteta i thin overcommit indikatora.
Get-Datastore |
  Select-Object Name, Type,
    @{N='CapacityGiB';E={[math]::Round($_.CapacityGB, 1)}},
    @{N='FreeGiB';E={[math]::Round($_.FreeSpaceGB, 1)}},
    @{N='UsedPct';E={
      if ($_.CapacityGB -gt 0) {
        [math]::Round((1 - $_.FreeSpaceGB / $_.CapacityGB) * 100, 1)
      }
    }} | Sort-Object UsedPct -Descending

Izvoz u CSV je lokalna promena na administratorskoj stanici, ne menja vSphere inventar. Fajl mora biti zaštićen jer može sadržati imena sistema i operativne podatke. Za ponovljivost zapiši vremensku zonu, vCenter, period, brojače, interval, verziju modula i vreme izvoza.

11. Pragovi, alarmi i governance

Prag nije jedna univerzalna cifra. Definiši warning, action i emergency nivo za svaki failure domain i resurs. Warning otvara analizu; action mora ostaviti dovoljno vremena za nabavku ili rightsizing; emergency aktivira ograničenje novih zahteva i incidentni postupak. Pragovi se odobravaju zajedno sa vlasnikom usluge i dokumentuju u CMDB-u ili capacity registru.

12. Tipični pogrešni zaključci i troubleshooting kapaciteta

Tok dijagnostike počinje potvrdom simptoma, scope-a i vremena. Sačuvaj dashboard/export, Tasks and Events, alarme i poslednje promene. Zatim proveri da li je problem fizički deficit, contention, neravnoteža, konfiguraciono ograničenje, degradirana putanja ili pogrešan model. Privremeno zaobilazno rešenje — na primer kontrolisana migracija VM-a — nije RCA. Trajna mera mora ukloniti osnovni uzrok, obnoviti rezervu, proći validaciju i ažurirati model.

Praktikum – od inventara do odobrenog capacity plana

Topologija, preduslovi i rizik

Laboratorija koristi jedan vCenter, klaster LAB-CL01 sa najmanje tri ESXi hosta, nekoliko VM-ova i najmanje jedan datastore. Ako postoje Aria Operations ili vSAN, njihove capacity prikaze koristi kao dodatni izvor, ali vežba mora biti izvodljiva i bez njih. Potrebni su vSphere Client, VCF PowerCLI i nalog sa read-only pristupom inventaru i performansama. Sve do posebno označenog scenarija postupci su read-only.

Vežba 1 – Utvrđivanje izvora i početnog stanja

1. U vSphere Client-u zabeleži vCenter version/build, ESXi version/build, licence i enabled funkcije klastera.
2. Izaberi zvanični Configuration Maximums skup koji tačno odgovara stanju. U radnom listu evidentiraj datum pristupa i najmanje pet relevantnih limita, ali ne prepisuj vrednosti iz drugog izdanja.
3. Pokreni read-only inventarske PowerCLI komande iz ove lekcije i sačuvaj rezultat u kontrolisanom direktorijumu.
4. Potvrdi da se broj hostova, VM-ova, datastore-a i verzije slažu sa vSphere Client-om. Neslaganje tretiraj kao problem scope-a, privilegija ili konekcije, ne kao podatak za plan.

Očekivani rezultat: verzijski označen inventar i dokaz da je odabran odgovarajući skup limita. Kriterijum završetka: svaki limit ima naziv, komponentu, verziju izvora, trenutnu vrednost i vlasnika provere.

Vežba 2 – Bazna linija i ograničavajući resurs

1. Izaberi reprezentativnih sedam dana za laboratoriju; u produkciji koristi puni poslovni ciklus.
2. Za klaster i svaki host prikupi CPU i memory metrike. Za datastore prikupi prostor, latency, IOPS i throughput gde su brojači dostupni.
3. Izračunaj average, p95 i maximum. Obeleži intervale sa alarmom, backup-om, vMotion-om ili poznatim testom.
4. Uporedi zbirni klaster sa najopterećenijim hostom i datastore-om. Identifikuj resurs koji prvi prelazi interni prag, ne samo resurs sa najvećim procentom.

Validacija: ručno proveri najmanje jedan p95 interval u vSphere Client grafikonu. Ako se vrednosti razlikuju, proveri vremensku zonu, sampling/rollup interval, scope i jedinicu. Rollback: nema promene vSphere stanja; obriši samo laboratorijski lokalni izvoz ako sadrži podatke koje ne smeš zadržati.

Vežba 3 – N−1 i maintenance scenario

1. Identifikuj host sa najvećim efektivnim CPU i memory kapacitetom.
2. Od ukupnog klasterskog kapaciteta oduzmi taj host, sistemski overhead, reservations i internu rezervu.
3. Uporedi rezultat sa p95 i dokumentovanim poslovnim vrhom; potom proveri da li najveći VM-ovi mogu biti smešteni na preostale kompatibilne hostove.
4. Pregledaj HA Admission Control i DRS/affinity pravila read-only. Za vSAN, ako postoji, pokreni pre-check/report za maintenance bez stvarnog ulaska hosta u maintenance mode.
5. Zabeleži rizik ako N−1 prolazi zbirno, ali ne prolazi zbog rezervacije, uređaja, pravila, fault domain-a ili storage/network ograničenja.

Očekivani rezultat: dokaz da klaster može ili ne može da podnese definisani failure/maintenance scenario. Kriterijum završetka: odluka sadrži ograničavajući resurs i konkretan korektivni zahtev, a ne samo oznaku „N+1”.

Vežba 4 – Prognoza rasta i prag za akciju

1. Na kopiji podataka simuliraj tri scenarija: 5%, 15% i 30% rasta demand-a, plus deset novih VM-ova standardnog profila.
2. Za svaki scenario ponovo izračunaj N−1 headroom i procenat relevantnog Configuration Maximums limita.
3. Dodaj lead time od, na primer, 90 dana kao laboratorijsku pretpostavku i odredi datum kada odluka mora biti doneta.
4. Predloži najmanje dve mere: rightsizing/reclaim i proširenje ili arhitektonska raspodela. Za svaku navedi rizik, uštedu/kapacitet, change zahtev i dokaz posle primene.

Validacija: nijedan scenario ne sme računati Configuration Maximums kao upotrebljiv kapacitet. Rollback: simulacija ne menja infrastrukturu; sačuvaj početne ulaze da bi model mogao biti reprodukovan.

Vežba 5 – Incident: „ima slobodnog kapaciteta, ali VM kasni”

U laboratorijskom izveštaju uvedi simptom da jedna VM ima visoko CPU Ready vreme tokom batch prozora, dok je sedmodnevni prosek klastera nizak. Ne generiši stres ako laboratorija nije izolovana.

1. Simptom i obim: potvrdi VM, korisnički uticaj, početak, trajanje i da li druge VM-ove imaju isti problem.
2. Dokazi: sačuvaj VM/host CPU usage, demand, Ready/Co-Stop, limits/reservations, DRS preporuke, affinity pravila i Tasks/Events za isti interval.
3. Hipoteza: razlikuj oversizing VM-a, host hotspot, CPU limit, pravilo smeštaja i fizički deficit.
4. Privremena mera: predloži kontrolisanu migraciju samo ako je cilj kompatibilan i ima headroom; to je state-changing akcija i zahteva change/incident odobrenje.
5. Trajna korekcija: uklanjanje pogrešnog limita, korekcija pravila, rightsizing ili dodavanje kapaciteta — samo prema potvrđenom uzroku.
6. Validacija: uporedi isti batch prozor pre i posle, proveri aplikacioni SLO, Ready/Co-Stop i odsustvo novog hotspot-a.
7. Rollback: ako se stanje pogorša, vrati prethodni VM resurs/pravilo ili migriraj na dokumentovani početni host, prema odobrenom planu.

Kriterijum završetka: izveštaj jasno razdvaja neposredni uzrok, osnovni uzrok, workaround i trajnu meru, sa dokazom oporavka.

Administratorske prakse

• Capacity review vodi periodično i posle velike promene, incidenta, migracije, promene retention-a ili uvođenja novog workload profila.
• Čuvaj verziju izvora, vremenski opseg, jedinice i metod proračuna; grafikon bez porekla nije audit dokaz.
• Razdvoji capacity, performance i configuration limit, ali ih procenjuj zajedno.
• Modeluj najveći relevantni failure domain, planirani maintenance i zajedničke storage/network zavisnosti.
• Automatizuj read-only inventar i izveštaj; svaku korektivnu promenu vodi kroz odobrenje, pre-check, rollback i post-check.
• Ne uklanjaj rezervu da bi dashboard privremeno postao zelen. Eskaliraj potražnju, rizik i rok razumljivim poslovnim jezikom.
• Posle proširenja potvrdi balans, kompatibilnost, HA/DRS stanje, storage putanje, alarmiranje i novu baznu liniju.

Završna kontrolna tačka

Nakon ove lekcije administrator treba da može da:

• razlikuje fizički, efektivni, upotrebljivi i preostali kapacitet;
• izabere reprezentativan period i protumači average, p95/p99, vrh, demand i contention;
• izradi CPU, memory, storage i network model koji uključuje HA i maintenance rezervu;
• proveri Configuration Maximums prema tačnoj verziji, komponenti, fusnotama i licenci;
• prikupi read-only inventar i performansne dokaze vSphere Client-om i VCF PowerCLI-jem;
• prepozna skriveno usko grlo iza niskog proseka ili velikog zbirnog slobodnog kapaciteta;
• izračuna osnovni, očekivani i stresni scenario i odredi datum za akciju prema lead time-u;
• dokumentuje prag, rizik, vlasnika, korektivnu meru, rollback i dokaz posle promene.

Zaključak

Zrelo planiranje kapaciteta spaja metrike, arhitekturu, dostupnost i poslovno vreme. Ono ne pita samo koliko resursa postoji, već koliko je zaista upotrebljivo kada otkaže host, traje maintenance, raste workload i paralelno rade backup ili migracije. Configuration Maximums štiti podržanost dizajna, ali ne određuje njegovu bezbednu radnu tačku. Administrator je odgovoran da između stvarne potražnje i zvanične granice ostavi dokazivu rezervu, da na vreme prepozna ograničavajući resurs i da svako proširenje ili optimizaciju sprovede kao kontrolisanu, merljivu promenu.