VMware & Tanzu

Prethodna lekcija proverila je da li su verzije vSphere-a, licence, ESXi hostovi i klasterske funkcije podržani za vSphere Supervisor i vSphere Kubernetes Service (VKS). Kompatibilnost je, međutim, samo uslov da platforma može da bude implementirana. Ova lekcija odgovara na teže pitanje: da li izabrana infrastruktura može da izdrži planirani broj klastera i aplikacija, gubitak komponente, redovno održavanje i rast, a da pri tome ostane u podržanom i operativno predvidivom stanju.

Plan kapaciteta nije zbir slobodnih CPU jezgara, memorije i terabajta u trenutku projektovanja. On je dokumentovana veza između poslovne potražnje, Kubernetes zahteva, vSphere načina raspoređivanja, mrežnih i storage ograničenja, ciljeva dostupnosti i rezervnog kapaciteta. Dobar plan mora da pokaže ne samo da workload može da se pokrene, već i da može da ostane pokrenut tokom kvara hosta ili zone, da može da se nadogradi i da se posle incidenta vrati u željeno stanje.

1. Od poslovne potražnje do merljivog infrastrukturnog zahteva

Kapacitet se planira od workload-a ka infrastrukturi, a ne od slobodnog hardvera ka workload-u. Ulazni podaci obuhvataju broj VKS klastera, broj i veličinu control plane i worker čvorova, broj namespace-a, vrste aplikacija, persistent volume zahteve, očekivani mrežni saobraćaj, režim nadogradnje, ciljeve oporavka i period rasta. Zahtev „potrebno je deset Kubernetes klastera” nije dovoljan: deset razvojnih klastera sa po jednim malim worker čvorom i deset produkcionih klastera sa višestrukim zonama predstavljaju potpuno različite sisteme.

Za svaki resurs razlikuju se četiri vrednosti: instalirani kapacitet, kapacitet koji je tehnički raspoloživ, kapacitet koji je bezbedno dodeljiv posle rezervi i trenutno zahtevani kapacitet. CPU overcommit može biti razuman za razvojne workload-e, ali memorija, IP adrese i storage moraju se planirati konzervativnije. Kubernetes scheduler posmatra deklarisane zahteve unutar klastera, dok vSphere raspoređuje virtuelne mašine koje nose te čvorove; prekomerna dodela na oba sloja može sakriti isti deficit dva puta.

Bezbedno dodeljiv kapacitet = instalirani kapacitet
                              - infrastrukturni overhead
                              - failover rezerva
                              - maintenance/upgrade rezerva
                              - operativna sigurnosna margina

Potrebni kapacitet = postojeća potražnja
                     + odobreni novi workload-i
                     + projektovani rast
                     + privremeni surge tokom nadogradnje

2. Management i compute nisu samo dve etikete

Management sloj obuhvata vCenter Server, mrežne i storage kontrolere, load balancer komponente, monitoring, backup i druge servise od kojih platforma zavisi. Compute sloj obezbeđuje resurse za Supervisor workload-e i VKS čvorove. Fizičko razdvajanje može smanjiti blast radius i sprečiti da aplikacioni skok potrošnje ugrozi upravljanje, ali povećava broj klastera, licenci, failure domain-a i operativnih zavisnosti. Konsolidacija je prihvatljiva u laboratoriji i nekim manjim okruženjima samo ako su rezervacije, admission control, prioriteti i rizik jasno dokumentovani.

Supervisor control plane nije običan tenant workload. Njegova dostupnost zavisi od ESXi hostova, vCenter-a, DNS-a, NTP-a, mreže, storage-a i izabranog load balancer modela. Zato se njegov resursni budžet ne „pozajmljuje” aplikacijama. Isto važi za sistemske namespace-e, CSI/CNI komponente, image registry i servise koji omogućavaju životni ciklus VKS klastera.

3. Failure domain, vSphere zona i granica kvara

Failure domain je skup resursa koji mogu istovremeno postati nedostupni zbog zajedničkog uzroka: jedan host, rack, PDU, top-of-rack switch, storage sistem, vSphere klaster, zgrada ili lokacija. vSphere Zone je eksplicitno modelovana granica koja se, u podržanoj zonalnoj Supervisor topologiji, mapira na vSphere klaster. Ove pojmove ne treba poistovetiti: etiketa zone ne stvara fizičku nezavisnost ako tri klastera dele isti PDU, mrežni uređaj ili storage failure domain.

Single-cluster Supervisor štiti od pojedinačnih kvarova u granicama jednog vSphere klastera, u meri u kojoj su HA, DRS, storage i mreža pravilno projektovani. Three-zone Supervisor raspoređuje upravljačke i podržane workload komponente preko tri vSphere zone i omogućava klastersku toleranciju gubitka zone. Zvanični zahtevi navode mapiranje svake zone na poseban vSphere klaster; preporučeni broj hostova može biti veći od tehničkog minimuma. Stretched-cluster dizajn je drugačiji model i ne sme se predstavljati kao sinonim za three-zone Supervisor. Podrška zavisi od konkretnog vSphere izdanja i storage/mrežne arhitekture.

4. Proračun CPU i memorijskog kapaciteta

Za početni proračun sabiraju se veličine svih VM klasa koje će koristiti Supervisor i VKS čvorovi, sistemski overhead, infrastrukturne VM i planirani surge. Zatim se rezultat proverava istorijskim metrikama. Broj vCPU nije jednak potrebnom broju fizičkih jezgara: prihvatljiv odnos zavisi od profila workload-a, NUMA topologije, CPU ready vremena, latency zahteva i politike overcommit-a. Visok prosečan procenat CPU-a može sakriti kratke vrhove, dok nizak prosek uz visok CPU ready ukazuje na konkurenciju.

Memorija se planira prema aktivnom radnom skupu i garantovanom oporavku. Ballooning, compression i swap su signali pritiska, a ne normalan izvor produkcionog kapaciteta za Kubernetes čvorove. Rezervacije za kritične upravljačke komponente mogu zaštititi platformu, ali istovremeno smanjuju kapacitet raspoloživ za HA admission control; zato se njihov efekat računa, ne pretpostavlja.

• Baseline: P95 ili drugi dogovoreni percentil iz reprezentativnog perioda, uz pregled vrhova i sezonskih obrazaca.
• N+1: preostali hostovi moraju prihvatiti zaštićeni workload posle gubitka najvećeg relevantnog hosta.
• Maintenance: plan mora istovremeno podržati host u maintenance režimu i očekivani nivo zaštite.
• Upgrade surge: Cluster API može privremeno kreirati zamenske mašine; bez dodatnog kapaciteta rolling update ostaje u stanju čekanja.
• Heterogeni hostovi: ne računati samo zbir; najslabiji placement domain, EVC/CPU kompatibilnost i veličina pojedinačne VM klase mogu postati ograničenje.

5. Storage kapacitet, performanse i topologija

Storage plan mora odvojiti kapacitet za Supervisor, VKS node diskove, persistent volume-e, image sadržaj, logove, snapshot-e, backup staging i privremeni prostor potreban tokom lifecycle operacija. Thin provisioning povećava efikasnost, ali ne stvara fizički prostor. Ako se ista slobodna količina obeća vSphere VM diskovima, Kubernetes PVC-ovima i snapshot-ima, deficit će se pojaviti u najnepovoljnijem trenutku.

SPBM politika definiše zaštitu i placement, pa korisni kapacitet može biti znatno manji od sirovog. U zonalnom dizajnu datastore pristupačnost mora odgovarati zoni i podržanom načinu rada. „Datastore je vidljiv” nije dovoljan dokaz: proveravaju se usklađenost politike, dostupnost svim predviđenim hostovima, latencija, IOPS, path redundansa i ponašanje pri gubitku komponente. Detaljna implementacija CSI-ja i stateful topologije obrađuje se u kasnijim storage lekcijama; ovde je cilj da se njihov budžet rezerviše pre aktivacije platforme.

6. Mrežni kapacitet nije samo propusnost

Plan obuhvata management adrese, Supervisor mreže, VKS node adrese, pod/service opsege kada ih izabrani mrežni model zahteva, ingress/egress i load balancer VIP pool. IP adrese se računaju po stanju u kome se klaster nadograđuje ili oporavlja, ne samo po stabilnom broju čvorova. Potrebna je i rezerva za nove klastere, zamenske mašine i orkestratorske objekte koji još nisu očišćeni posle neuspele operacije.

Potrebne node IP adrese = postojeći čvorovi
                          + odobreni novi čvorovi
                          + maksimalni paralelni upgrade surge
                          + failover/repair rezerva
                          + operativna margina

Pored adresnog prostora proveravaju se redundantni uplinkovi, MTU duž cele putanje, east-west i north-south propusnost, ECMP/BGP kapacitet gde je primenljiv, broj load balancer servisa, NAT i firewall state tabela, DNS i NTP dostupnost. Iscrpljen IP pool može ostaviti VKS mašinu u stanju Provisioning i blokirati oporavak upravo kada je dodatni čvor najpotrebniji.

7. HA, DRS, admission control i rezervni kapacitet

vSphere HA restartuje VM posle kvara hosta, ali ne može da stvori resurse koji ne postoje. Admission control rezerviše mogućnost failover-a; njegovo upozorenje je dokaz da dizajn ili trenutno stanje više ne zadovoljavaju politiku, a ne smetnja koju treba rutinski isključiti. DRS poboljšava placement i balans, ali njegov uspeh zavisi od kompatibilnosti hostova, mrežne i storage dostupnosti, affinity pravila i dovoljnog prostora za migraciju.

Za heterogene klastere koristi se konzervativni scenario gubitka najvećeg hosta. Za zonalni dizajn računa se gubitak cele zone i proverava da li preostale zone nose kritični workload bez kršenja limita. Ako je cilj samo kontrolisano gašenje manje važnih workload-a, taj kompromis se dokumentuje prioritetima, Runbook-om i testom; ne ostavlja se implicitno scheduler-u.

8. Rast platforme i pragovi za odluku

Forecast treba da pokrije najmanje vreme potrebno za nabavku, instalaciju, firmware/driver usklađivanje, testiranje i prijem novih hostova. Linearna projekcija je polazna tačka, ali se dopunjuje poznatim projektima, sezonskim vrhovima i diskretnim skokovima kao što su novi VKS klaster, nova zona ili promena politike replika.

Pragovi se ne zasnivaju samo na procentu korišćenja. Klaster sa 40% slobodne memorije može biti nebezbedan ako jedan host nosi 35% ukupne memorije, a klaster sa 20% slobodnog CPU-a može biti prihvatljiv za burst workload ako CPU ready i latencija ostaju u granicama. Svaki prag zato sadrži metriku, vremenski prozor, failure scenario, vlasnika i unapred definisanu akciju.

9. Dokument dizajna i evidencija pretpostavki

Plan kapaciteta mora biti ponovljiv. Za svaku brojku čuva se izvor, datum, verzija proizvoda, formula, sigurnosna margina i vlasnik pretpostavke. Posebno se vode otvorena pitanja: buduća aplikacija bez merenja, nepotvrđen storage profil, neodobren IP opseg ili licenca koja još nije obezbeđena. Neizvesnost se ne skriva iza preciznog zbira.

• logički i fizički dijagram sa failure domain-ima i zajedničkim zavisnostima;
• inventar hostova, CPU/NUMA, memorije, NIC/HBA i firmware/driver kompatibilnosti;
• katalog VM klasa i VKS profila sa kvotama i vlasnicima;
• CPU, RAM, storage, IP i VIP budžet za stabilno, failover i upgrade stanje;
• HA/DRS, affinity i admission control odluke;
• forecast, pragovi, lead time i plan proširenja;
• testovi prihvatanja, poznati rizici, rollback i datum sledeće revizije.

Praktikum: izrada dokazivog plana kapaciteta

Cilj: prikupiti read-only inventar i istorijske metrike vSphere klastera, prevesti plan VKS workload-a u resursni budžet, proveriti N+1 i upgrade scenario i izraditi odluku spremno/uslovno spremno/nije spremno. Vežba ne aktivira Supervisor i ne menja HA, DRS, mrežu ni storage.

Topologija laboratorije: jedan vCenter Server, jedan kandidat workload klaster sa najmanje tri ESXi hosta, najmanje jedan zajednički datastore i distribuirana mreža. Ako se procenjuje three-zone dizajn, podaci se prikupljaju za tri odvojena vSphere klastera i za svaku zonu se vodi zaseban bilans.

Nalozi i alati: vSphere nalog sa read-only pristupom inventaru, performansama, događajima i alarmima; administrativna radna stanica sa PowerShell-om i aktuelnim VMware/VCF PowerCLI modulom; pristup odobrenom IPAM izvozu i katalogu StorageClass/SPBM politika. Kredencijale ne zapisivati u skriptu.

Rizik: nizak, jer su sve komande u osnovnom toku read-only. Izvoz može sadržati imena sistema i kapacitet, pa se čuva kao interni dokument. Sve opcione state-changing akcije izdvojene su i ne izvršavaju se u produkciji bez change odobrenja.

Vežba 1: inventar hostova, klastera i datastore-a

1. U vSphere Client-u otvorite kandidat klaster i proverite Summary, Monitor > Performance, Monitor > Tasks and Events, Configure > vSphere Availability i Configure > vSphere DRS. Zabeležite HA admission control politiku, DRS režim, aktivne alarme i hostove u maintenance/disconnected stanju.
2. Na administratorskoj stanici povežite se sa vCenter Server-om. Komanda menja samo lokalnu sesiju i ne konfiguriše vCenter.

Import-Module VMware.PowerCLI
Connect-VIServer -Server vcsa.lab.example

3. Prikupite inventar. Zamenite naziv klastera stvarnom vrednošću. Komande su read-only.

$cluster = Get-Cluster -Name 'TANZU-COMPUTE-01'
$hosts = $cluster | Get-VMHost | Sort-Object Name

$hosts | Select-Object Name, ConnectionState, PowerState,
  @{N='CpuSockets';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuPackages}},
  @{N='CpuCores';E={$_.NumCpu}},
  @{N='CpuGHzTotal';E={[math]::Round($_.CpuTotalMhz / 1000, 1)}},
  @{N='MemoryGiB';E={[math]::Round($_.MemoryTotalGB, 1)}} |
  Format-Table -AutoSize

$cluster | Get-Datastore |
  Select-Object Name, Type,
    @{N='CapacityGiB';E={[math]::Round($_.CapacityGB, 1)}},
    @{N='FreeGiB';E={[math]::Round($_.FreeSpaceGB, 1)}},
    @{N='FreePercent';E={if ($_.CapacityGB) {[math]::Round(100 * $_.FreeSpaceGB / $_.CapacityGB, 1)}}} |
  Sort-Object FreePercent |
  Format-Table -AutoSize

Očekivani rezultat: svi planirani hostovi su Connected i PoweredOn, njihove konfiguracije odgovaraju dizajnu, a datastore-i imaju dokumentovan slobodan i korisni kapacitet. Ukupni zbir nije dovoljan ako VKS VM klase ne mogu da stanu na pojedinačni host ili ako datastore nije dostupan svim hostovima predviđenog placement domain-a.

Troubleshooting grana: ako host nije povezan, datastore ima neuobičajeno malo slobodnog prostora ili je HA degradiran, ne „popravljajte” broj u tabeli. Zabeležite simptom, vreme, obim i poslednje promene; pregledajte događaje i alarme; otvorite poseban incident ili change. Plan kapaciteta označite kao uslovan dok se osnovni uzrok ne ukloni.

Vežba 2: istorijske CPU i memorijske metrike

Jednokratni screenshot nije baseline. Sledeći primer čita dostupne realtime uzorke za poslednja dva sata. Za ozbiljan sizing koristite duži istorijski period i interval koji vCenter zaista zadržava; dostupne metrike proveravaju se pomoću Get-StatType i Get-StatInterval.

$start = (Get-Date).AddHours(-2)
$metrics = 'cpu.usage.average','cpu.ready.summation',
           'mem.usage.average','mem.active.average',
           'mem.vmmemctl.average','mem.swapused.average'

Get-Stat -Entity $hosts -Stat $metrics -Start $start -Realtime |
  Group-Object Entity, MetricId |
  ForEach-Object {
    $values = $_.Group.Value | Sort-Object
    $p95Index = [math]::Floor(($values.Count - 1) * 0.95)
    [pscustomobject]@{
      Series  = $_.Name
      Samples = $values.Count
      Average = [math]::Round(($_.Group | Measure-Object Value -Average).Average, 2)
      P95     = [math]::Round($values[$p95Index], 2)
      Maximum = [math]::Round(($values | Measure-Object -Maximum).Maximum, 2)
    }
  } | Format-Table -AutoSize

Tumačenje: procenat cpu.usage.average čita se zajedno sa CPU ready vremenom; cpu.ready.summation je zbir milisekundi u intervalu i ne treba ga neposredno tretirati kao procenat bez poznavanja intervala i broja vCPU. Ballooning i swap zahtevaju korelaciju sa memorijskim pritiskom i konkretnim VM-ovima. Ako metrika ne postoji u izabranom intervalu, to nije nula već nedostajući dokaz.

Validacija: uporedite rezultat sa vSphere Client grafikonima za isti vremenski prozor i proverite vremensku zonu. Za sezonski workload izvezite podatke za reprezentativne radne i neradne dane. Dokumentujte rupe u telemetriji.

Vežba 3: VKS demand model i N+1 proračun

Napravite tabelu svake planirane VM klase. Primer ispod je didaktički i ne predstavlja fabrički minimum niti preporučenu klasu. Vrednosti moraju doći iz odobrenog kataloga za konkretno izdanje.

Za N+1 izračunajte raspoloživ kapacitet posle uklanjanja najvećeg hosta, zatim oduzmite infrastrukturni overhead, postojeće zaštićene VM, rezervacije i maintenance marginu. Za three-zone dizajn isti postupak se izvodi posle uklanjanja cele najveće zone. Provera mora obuhvatiti i placement: najveća planirana VM mora moći da stane na odgovarajući pojedinačni host.

Scenario A – zdravo stanje:
  Bezbedno dodeljiv CPU/RAM/IP/storage ≥ zahtev + rast + upgrade surge

Scenario B – najveći host nije dostupan:
  Preostali bezbedno dodeljiv kapacitet ≥ kritični zahtev + repair surge

Scenario C – najveća zona nije dostupna:
  Preostale zone ≥ unapred definisan kritični servisni nivo

Rezultat:
  SPREMNO            svi obavezni scenariji prolaze
  USLOVNO SPREMNO    prolazi uz dokumentovanu meru i rok
  NIJE SPREMNO       failover, održavanje ili rast nemaju dokaziv kapacitet

Vežba 4: IP i VIP budžet

1. Iz IPAM-a izvezite ukupan broj adresa u svakom relevantnom pool-u, rezervisane adrese, trenutno dodeljene adrese i karantin/lease period.
2. Izračunajte stabilno stanje, najveći planirani rolling upgrade, istovremeni repair i rast do sledeće nabavke/proširenja opsega.
3. Proverite preklapanje CIDR opsega sa management, VPN, pod, service i povezanim mrežama. Proverite rute, gateway, DNS i load balancer ograničenja.
4. Postavite planerski prag pre tehničkog iscrpljenja. Vlasnik pool-a mora dobiti alarm dovoljno rano da proširenje može biti odobreno i sprovedeno.

Očekivani rezultat: nijedan scenario kreiranja, nadogradnje ili oporavka ne zahteva više adresa ili VIP-ova nego što je bezbedno raspoloživo. Ako nedostaje IP prostor, bezbedna korektivna akcija je promena dizajna ili kontrolisano proširenje pool-a kroz dokumentovani postupak; ručno brisanje objekata samo radi oslobađanja adrese nije prihvatljivo bez potvrde da su zaista orphaned i bez vendor postupka.

Vežba 5: storage i operativni rezervni prostor

1. Za svaku SPBM politiku utvrdite nominalni zahtev, zaštitni overhead, failure domain i stvarni korisni kapacitet. Ne sabirajte datastore-e koji nisu zamenjivi za isti workload.
2. Dodajte VKS node diskove, maksimalan PVC rast, snapshot/backup retention i privremeni prostor za upgrade, evacuaciju i resync.
3. Proverite istorijske latency/IOPS/throughput metrike u normalnom i degradiranom periodu. Slobodni GiB bez performansnog kapaciteta ne predstavljaju validan rezultat.
4. Dokumentujte alarmni prag i akciju. Prag mora ostaviti dovoljno prostora za oporavak, a ne samo za još jedan workload.

Kriterijum uspeha: storage politika je usklađena, placement je moguć u predviđenoj zoni, a kapacitet i performanse zadovoljavaju zdravo, maintenance i failover stanje. Detaljna provera PVC, snapshot, backup i restore funkcionalnosti sledi u storage lekcijama.

Vežba 6: simulacija odbijenog plana bez izazivanja kvara

Ne gasite host i ne punite datastore. U kopiji proračuna uvedite hipotetički kvar najvećeg hosta, zatim povećajte worker pool za jednu zamensku VM i smanjite slobodan IP pool za planirani surge. Zabeležite koji resurs prvi krši prag. Time se proverava logika plana bez state-changing operacije.

Redosled dijagnostike je: sačuvati vreme i identitet objekta; proveriti poslednje promene; pregledati Supervisor/VKS status, vCenter događaje i alarme; proveriti host, HA/DRS, datastore i IP pool; formirati hipotezu; potvrditi je najmanje invazivnom proverom; sprovesti odobrenu korekciju; validirati kreiranje/oporavak; dokumentovati osnovni uzrok i ažurirati forecast.

Rollback i povratak laboratorije

Osnovni praktikum ne menja stanje, pa se rollback svodi na prekid PowerCLI sesije i bezbedno čuvanje ili uklanjanje izvoza u skladu sa politikom podataka.

Disconnect-VIServer -Server vcsa.lab.example -Confirm:$false

Ako je u odvojenom, odobrenom laboratorijskom change-u menjana HA/DRS politika, IP pool ili kvota, pre promene mora postojati izvoz početnog stanja i tačno definisana povratna vrednost. Vraćanje se izvodi istim upravljačkim slojem kojim je promena napravljena, zatim se proveravaju alarmi, admission control, DRS health, Supervisor status i mogućnost kreiranja test objekta. Produkcione postavke se ne vraćaju napamet prema laboratorijskom primeru.

Administratorske prakse

• Kapacitet posmatrajte kao SLO zavisnost, a ne kao godišnju Excel vežbu.
• Odvojeno vodite zdravo, maintenance, upgrade i failover stanje.
• Svaku zonu i svaki nezamenjiv resurs merite zasebno; zbir može sakriti lokalno usko grlo.
• Ne računajte ballooning, swap, thin-provisioning obećanje ili neodobren IP opseg kao raspoloživ kapacitet.
• Za kvote, VM klase i autoscaling koristite isti demand model; različiti administrativni slojevi ne smeju obećati isti resurs više puta.
• Pre state-changing korekcije sačuvajte događaje, alarme, metrike, poslednje promene i tačan identitet objekta.
• Posle svakog većeg onboarding-a, nadogradnje ili incidenta ažurirajte pretpostavke, pragove i lead time.
• Failure-domain mapu proverite sa timovima za napajanje, mrežu i storage; vCenter inventar sam ne otkriva sve zajedničke zavisnosti.

Završna kontrolna tačka

Lekcija je završena kada administrator može dokazima da:

• prevede planirani broj VKS klastera, VM klasa, worker pool-ova i stateful workload-a u CPU, RAM, storage, IP i VIP zahtev;
• razlikuje instalirani, raspoloživi, bezbedno dodeljivi i zahtevani kapacitet;
• objasni razliku između single-cluster, three-zone i stretched-cluster modela bez mešanja zone sa stvarnom fizičkom nezavisnošću;
• izračuna N+1, maintenance, failover i upgrade surge scenario i identifikuje prvi ograničavajući resurs;
• PowerCLI read-only komandama prikupi inventar i metrike, pravilno protumači vremenski interval i prepozna nedostajući dokaz;
• postavi planerske i operativne pragove povezane sa konkretnom akcijom i rokom nabavke;
• odbije dizajn koji radi samo u zdravom stanju ili zavisi od neproverene kompatibilnosti, adresa, storage politike ili zajedničke komponente;
• dokumentuje simptom, neposredni i osnovni uzrok, privremenu meru, trajnu korekciju i validaciju oporavka.

Zaključak

Dobro planirana Tanzu platforma nije ona koja danas može da pokrene sve tražene VM, već ona čije su granice poznate i dokazive u zdravom stanju, tokom održavanja, pri nadogradnji i posle kvara. Management i compute sloj, vSphere zone, HA/DRS, storage politike, mrežni pool-ovi i Kubernetes zahtevi čine jedan kapacitivni sistem; deficit u bilo kom od njih može zaustaviti kreiranje, skaliranje ili oporavak VKS klastera.

Administratorska odgovornost je da pretpostavke pretvori u merljive zahteve, odvoji tehnički minimum od produkcione preporuke, očuva rezervu za kvar i lifecycle operacije i pokrene proširenje pre nego što platforma izgubi manevarski prostor. Tako pripremljen plan postaje ulaz za naredne lekcije o DNS-u, NTP-u, IPAM-u, sertifikatima i readiness proceni, a kasnije i za kvote, VM klase, storage topologiju, observability i disaster recovery.