VMware

Drugi deo: Napredna administracija zajedničke infrastrukture
Datastore – mesto gde žive virtuelne mašine i njihovi diskovi
VI. Skladištenje, politike i integritet podataka
26. Datastore – logički prostor za datoteke virtuelnih mašina

Datastore predstavlja logički prostor za skladištenje podataka koji ESXi hostovi koriste za čuvanje virtuelnih mašina, virtuelnih diskova, template-a, ISO slika, snapshot datoteka, logova i drugih objekata potrebnih za rad VMware infrastrukture. Za administratora datastore nije samo „disk na kojem se nalazi VM”, već centralna tačka u kojoj se susreću fizički storage, storage protokoli, VMware filesystem, virtuelne mašine, dostupnost, performanse, backup i oporavak sistema.

Kada se kreira virtuelna mašina, administrator bira datastore na kojem će biti smešteni njeni konfiguracioni fajlovi i virtuelni diskovi. ESXi zatim koristi taj datastore kao skladišni prostor iz kojeg čita podatke potrebne za pokretanje VM-a i u koji upisuje sve promene nastale tokom njegovog rada.

Ako je datastore nedostupan, virtuelna mašina može ostati bez pristupa svom konfiguracionom fajlu ili virtuelnim diskovima. Posledice mogu biti usporenje aplikacija, zamrzavanje operativnog sistema gosta, neuspešno pokretanje VM-a, prekid backup poslova ili potpuni prekid rada servisa. Zbog toga storage predstavlja jednu od najvažnijih oblasti VMware administracije.

Datastore nije isto što i fizički disk

Datastore predstavlja logičku apstrakciju storage prostora. Ispod njega se može nalaziti lokalni disk, RAID grupa, SAN LUN, NFS export, vSAN kapacitet ili storage sistem koji koristi Virtual Volumes.

Osnovni slojevi mogu se predstaviti ovako:

Fizički diskovi ili flash uređaji
              │
              ▼
RAID grupa, storage pool ili disk grupa
              │
              ▼
LUN, NFS export, vSAN kapacitet ili storage container
              │
              ▼
Storage protokol i pristupna mreža
              │
              ▼
VMFS, NFS, vSAN ili vVol datastore
              │
              ▼
Folderi virtuelnih mašina
              │
              ▼
VMX, VMDK, snapshot-i, logovi i ostale datoteke

Kvar fizičkog diska ne mora automatski značiti gubitak datastore-a ako storage sistem koristi odgovarajući RAID, replikaciju ili drugi mehanizam zaštite. Sa druge strane, potpuno ispravan storage sistem može postati nedostupan ESXi hostu ako postoji problem sa SAN putanjom, iSCSI mrežom, NFS servisom, zoning konfiguracijom, autentifikacijom ili VMkernel mrežom.

Najčešći tipovi datastore-a

VMFS datastore

VMFS, odnosno VMware Virtual Machine File System, predstavlja klasterovani filesystem namenjen blok storage uređajima. Koristi se nad lokalnim diskovima, Fibre Channel LUN-ovima, iSCSI LUN-ovima, Fibre Channel over Ethernet uređajima i drugim kompatibilnim blok storage sistemima.

Klasterovana priroda VMFS-a omogućava da više ESXi hostova istovremeno pristupa istom datastore-u. VMware mehanizmi zaključavanja sprečavaju da dva hosta istovremeno na neispravan način menjaju iste datoteke virtuelne mašine.

U savremenim vSphere okruženjima standardni format je VMFS 6. Prilikom kreiranja novog datastore-a treba koristiti format koji odgovara verziji i kompatibilnosti hostova u konkretnom okruženju.

NFS datastore

NFS datastore koristi mrežni filesystem koji storage server ili NAS uređaj izlaže ESXi hostovima. Za razliku od VMFS-a, gde VMware kreira filesystem nad blok uređajem, kod NFS-a filesystem održava NFS server, dok ESXi mountuje izvezeni direktorijum.

vSphere podržava NFS 3 i NFS 4.1. Izbor verzije utiče na način autentifikacije, multipathing, mrežnu konfiguraciju i podržane funkcionalnosti. NFS storage zahteva pouzdanu VMkernel mrežu, pravilno podešen export i odgovarajuće dozvole za ESXi hostove.

Važna verzijska razlika postoji kod vezivanja NFS saobraćaja za VMkernel adapter. NFS 4.1 podržava više serverskih adresa radi multipathing-a, ali je eksplicitni VMkernel port binding za NFS 4.1 uveden u ESXi 8.0 Update 3. Zato postupak iz starijeg vSphere izdanja ne treba prenositi bez provere na 8.0 U3 ili novije okruženje. NFS 3 i NFS 4.1 datastore ne treba montirati na istom hostu prema istom export-u, jer te verzije koriste različite modele zaključavanja i takva kombinacija nije podržan način zajedničkog pristupa istim datotekama.

vSAN datastore

vSAN kombinuje lokalne diskove ili flash uređaje ESXi hostova u distribuirani datastore klastera. Dostupnost podataka ne određuje samo tradicionalni RAID, već storage politike virtuelnih mašina kojima se definišu tolerancija na kvarove, broj kopija podataka, način kodiranja i druge karakteristike.

vSAN datastore se ne administrira na isti način kao klasični VMFS LUN. Njegovo stanje zavisi od zdravlja hostova, disk grupa, mreže, storage politika i usklađenosti objekata.

vVol datastore

Virtual Volumes omogućavaju da storage sistem upravlja objektima virtuelnih mašina na granularnijem nivou. Umesto da veliki broj VM-ova bude smešten unutar jednog tradicionalnog LUN-a, storage funkcionalnosti se mogu primenjivati prema zahtevima pojedinačnih virtuelnih mašina i njihovih diskova.

vVol arhitektura se oslanja na VASA provider, storage container i protokol endpoint. Njena dostupnost zato zavisi i od pravilne komunikacije vCenter Servera sa VASA providerom.

Lokalni i deljeni datastore

Lokalni datastore dostupan je samo hostu na kojem se fizički nalazi. Pogodan je za laboratorijska okruženja, privremene virtuelne mašine, određene servisne VM-ove ili specifične arhitekture, ali sam po sebi ne omogućava drugim hostovima da pristupe istim VM datotekama.

Deljeni datastore dostupan je većem broju ESXi hostova. On predstavlja važan uslov za klasične scenarije u kojima HA nakon pada jednog hosta registruje i pokreće virtuelnu mašinu na drugom hostu. Deljeni storage takođe pojednostavljuje compute vMotion, jer se tokom migracije hosta lokacija VMDK datoteka ne mora menjati.

Treba razlikovati sledeće operacije:

Šta se nalazi u folderu virtuelne mašine

Svaka virtuelna mašina najčešće ima poseban folder na datastore-u. Nazivi i broj datoteka zavise od konfiguracije VM-a, broja diskova, snapshot-a, tipa firmware-a i trenutnog stanja virtuelne mašine.

/vmfs/volumes/PROD-VMFS01/APP-SRV01/

APP-SRV01.vmx
APP-SRV01.vmdk
APP-SRV01-flat.vmdk
APP-SRV01.nvram
APP-SRV01.vmsd
APP-SRV01.vswp
vmware.log
vmware-1.log

Najvažnije datoteke su:

Administrator ne treba ručno da briše, preimenuje ili menja VMDK, snapshot, VMX i druge datoteke dok prethodno ne utvrdi njihovu ulogu i međusobne veze. Datoteka koja deluje kao stari disk može biti deo aktivnog snapshot lanca. Njeno brisanje može trajno oštetiti virtuelnu mašinu.

Kako ESXi identifikuje datastore

Datastore ima prikazano ime i jedinstveni identifikator, odnosno UUID. Putanja sa imenom datastore-a obično predstavlja simboličku vezu ka UUID putanji.

ls -l /vmfs/volumes

Primer:

PROD-VMFS01 -> 681f2b5a-a1b2c3d4-1122-001122334455
ISO-NFS01   -> 9f21a611-55aa77cc

Putanja:

/vmfs/volumes/PROD-VMFS01

lakša je za svakodnevni rad, dok UUID ostaje važan tokom troubleshooting-a, posebno ako se ime promeni, datastore postane nemontiran ili ESXi otkrije snapshot kopiju VMFS volumena.

Prikaz datastore-a u vSphere Client-u

U vSphere Client-u administrator može otvoriti:

Menu → Storage → Datastores

ili izabrati host i otvoriti:

Host → Configure → Storage → Datastores

Za svaki datastore treba proveriti:

Datastore Browser

Datastore Browser omogućava pregled foldera i datoteka, upload i download određenih objekata, kreiranje direktorijuma i obavljanje osnovnih operacija nad sadržajem datastore-a.

Tipične bezbedne aktivnosti su:

Datastore Browser nije zamena za backup alat niti treba da se koristi za nasumično ručno kopiranje aktivnih VM datoteka. Datoteke VM-a mogu biti zaključane, međusobno zavisne ili promenjene tokom kopiranja.

Pregled datastore-a kroz ESXi Shell

Komande u ovom odeljku su read-only i bezbedne su za prikupljanje početnih dokaza, osim kada je izričito navedeno da komanda radi rescan, mount ili unmount i time menja stanje. ESXi Shell ili SSH treba omogućiti samo prema operativnoj politici, koristiti nalog sa potrebnim privilegijama, a po završetku privremeni pristup ponovo ograničiti.

Za rad kroz ESXi Shell ili SSH pristup najpre treba utvrditi koje filesystem-e host vidi:

esxcli storage filesystem list

Komanda prikazuje mount point, naziv, UUID, mount status, tip, veličinu i slobodan prostor.

Primer skraćenog izlaza:

Mount Point                              Volume Name    Mounted  Type   Size          Free
---------------------------------------  -------------  -------  -----  ------------  ------------
/vmfs/volumes/681f2b5a-a1b2c3d4         PROD-VMFS01    true     VMFS-6 2198754826240  780123013120
/vmfs/volumes/9f21a611-55aa77cc          ISO-NFS01      true     NFS    1099511627776  650123456512

Za prikaz VMFS volumena i uređaja na kojima se nalaze koristi se:

esxcli storage vmfs extent list

Ova komanda povezuje naziv VMFS datastore-a sa njegovim UUID-om, brojem extent-a, canonical nazivom uređaja i particijom.

Pregled storage adaptera:

esxcli storage core adapter list

Pregled storage uređaja:

esxcli storage core device list

Sažetiji pregled uređaja:

esxcli storage core device list -c

Pregled aktivnih putanja:

esxcli storage core path list

Pregled NMP uređaja i aktivnih multipathing politika:

esxcli storage nmp device list

Pregled sadržaja datastore-a:

ls -lah /vmfs/volumes/PROD-VMFS01

Pregled karakteristika određenog filesystem-a:

vmkfstools -P /vmfs/volumes/PROD-VMFS01

Za prikaz zauzeća datastore-a može se koristiti:

vdf -h

Komanda df -h prvenstveno prikazuje ESXi sistemske filesystem-e i ne treba je smatrati glavnom komandom za analizu VMFS kapaciteta. Za datastore-e su precizniji esxcli storage filesystem list, vdf -h i podaci iz vCenter Servera.

Pronalaženje VM-a i njegovih datoteka kroz CLI

Lista registrovanih virtuelnih mašina dobija se komandom:

vim-cmd vmsvc/getallvms

Primer:

Vmid  Name        File
12    APP-SRV01   [PROD-VMFS01] APP-SRV01/APP-SRV01.vmx
18    DB-SRV01    [PROD-VMFS02] DB-SRV01/DB-SRV01.vmx

Na ovaj način administrator brzo povezuje VM sa datastore-om i putanjom konfiguracionog fajla.

Za pronalaženje VMDK referenci iz VMX konfiguracije može se koristiti:

grep -i "fileName" /vmfs/volumes/PROD-VMFS01/APP-SRV01/APP-SRV01.vmx

Ovu komandu treba koristiti samo za pregled. Ručna izmena VMX fajla zahteva prethodni backup, razumevanje konfiguracije i odgovarajuću proceduru.

Pregled datastore-a preko PowerCLI-ja

Povezivanje sa vCenter Serverom:

Connect-VIServer -Server vcsa.lab.local

Prikaz svih datastore-a:

Get-Datastore

Pregled osnovnih podataka:

Get-Datastore |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB

Izračunavanje procenta slobodnog prostora:

Get-Datastore |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB,
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }} |
Sort-Object FreePercent

Pronalaženje datastore-a sa manje od 20 procenata slobodnog prostora:

Get-Datastore |
Where-Object {
    $_.CapacityGB -gt 0 -and
    (($_.FreeSpaceGB / $_.CapacityGB) * 100) -lt 20
} |
Select-Object Name,
              CapacityGB,
              FreeSpaceGB,
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }}

Prikaz hostova povezanih sa datastore-om:

$datastore = Get-Datastore -Name "PROD-VMFS01"

Get-VMHost |
Where-Object {
    (Get-Datastore -VMHost $_).Name -contains $datastore.Name
} |
Select-Object Name, ConnectionState, PowerState

Prikaz virtuelnih mašina koje koriste određeni datastore:

Get-Datastore -Name "PROD-VMFS01" |
Get-VM |
Select-Object Name, PowerState, VMHost

Izvoz izveštaja:

Get-Datastore |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB,
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }} |
Export-Csv -Path "./datastore-report.csv" -NoTypeInformation

Datastore i prostor koji VM stvarno koristi

Kapacitet konfigurisanog virtuelnog diska i fizički zauzet prostor na datastore-u nisu uvek isti. Kod thin provisioned diska može biti konfigurisan kapacitet od 500 GB, dok je na datastore-u trenutno zauzeto samo 80 GB. Kako gost upisuje nove blokove, zauzeće raste.

Na datastore kapacitet utiču:

Administrator zato ne sme planirati kapacitet samo na osnovu zbira veličina aktivnih VMDK diskova. Potrebna je rezerva za rast, operativne aktivnosti i nepredviđene događaje.

Datastore i snapshot-i

Snapshot ne predstavlja potpunu nezavisnu kopiju virtuelne mašine. Nakon kreiranja snapshot-a, novi upisi se usmeravaju u delta datoteku, dok bazni disk ostaje deo aktivnog lanca. Delta datoteka može rasti sve dok postoji slobodan prostor na datastore-u.

Dugotrajni snapshot-i mogu izazvati:

Pre brisanja velikog snapshot-a treba proveriti slobodan kapacitet, stanje VM-a, trajanje snapshot-a, aktivne backup poslove i očekivano opterećenje storage sistema. Operacija „Delete” uklanja snapshot iz lanca konsolidacijom podataka; ona ne znači jednostavno trenutno brisanje jedne male datoteke.

Datastore i HA

vSphere HA mora imati mogućnost da na preživelom hostu pristupi konfiguraciji i diskovima virtuelne mašine koju treba ponovo pokrenuti. Kod klasičnog shared-storage modela to znači da svi relevantni hostovi moraju videti datastore na kojem se VM nalazi.

Ako samo jedan host izgubi storage putanju, a ostali hostovi datastore i dalje vide, problem nije isti kao potpuni kvar storage sistema. Administrator mora utvrditi da li je kvar:

Ova razlika određuje da li treba raditi rescan jednog hosta, proveriti HBA ili VMkernel interfejs, uključiti storage tim, migrirati VM-ove ili aktivirati širi incidentni postupak.

Datastore i backup

Backup alat često kreira privremeni snapshot kako bi dobio konzistentnu tačku iz koje čita podatke virtuelnog diska. Ako backup traje dugo, snapshot delta može značajno porasti. Ako backup ne završi pravilno, snapshot ili zahtev za konsolidaciju mogu ostati iza njega.

Zbog toga se kod naglog rasta datastore-a proveravaju:

Backup kopija ne treba da bude smeštena samo na istom datastore-u kao produkcioni VM. Kvar datastore-a tada bi istovremeno ugrozio i primarne podatke i backup.

Performanse datastore-a

Veliki slobodan kapacitet ne znači automatski dobre performanse. Datastore može imati dovoljno prostora, a da VM-ovi ipak rade sporo zbog visoke latencije, nedovoljnog broja diskova, zasićenih storage kontrolera, problema sa putanjama ili velikog broja istovremenih I/O operacija.

Važni pokazatelji su:

U vSphere Client-u performanse se proveravaju izborom datastore-a ili hosta i otvaranjem:

Monitor → Performance → Advanced

Za realnu dijagnostiku treba posmatrati korelaciju između VM, host i datastore metrika. Jedan spor VM ne mora značiti spor datastore, dok istovremeno usporenje većeg broja VM-ova na istom datastore-u snažno ukazuje na zajednički storage problem.

Praćenje storage-a kroz esxtop

Komanda:

esxtop

zatim taster:

u

otvara prikaz storage uređaja. U zavisnosti od prikaza i verzije, administrator prati metrike kao što su:

Visoka DAVG vrednost obično usmerava analizu ka storage uređaju, fabric mreži ili storage sistemu. Visoka KAVG vrednost može ukazivati na redove i zadržavanje unutar hosta. GAVG predstavlja zbir različitih komponenti kašnjenja i pokazuje ukupan efekat koji radno opterećenje oseća.

Vrednosti se moraju tumačiti u kontekstu konkretnog storage sistema i njegovih očekivanih performansi. Jedan trenutni skok nije isto što i trajna povišena latencija tokom perioda u kojem aplikacije prijavljuju problem.

Rescan storage adaptera

Kada storage tim predstavi novi LUN ili se putanja ponovo uspostavi, ESXi host mora osvežiti pogled na storage uređaje.

Pregled adaptera:

esxcli storage core adapter list

Rescan svih adaptera:

esxcli storage core adapter rescan --all

Nakon toga proverava se:

esxcli storage core device list
esxcli storage vmfs extent list
esxcli storage filesystem list

Rescan ne treba koristiti kao nasumično rešenje za svaki storage problem. Pre izvršavanja u produkciji treba razumeti obim incidenta, stanje storage sistema i moguće posledice većeg broja istovremenih rescan operacija na svim hostovima.

Montiranje i demontiranje datastore-a

Pregled montiranih i nemontiranih filesystem-a:

esxcli storage filesystem list

Montiranje prema labeli:

esxcli storage filesystem mount -l PROD-VMFS01

Montiranje prema UUID-u:

esxcli storage filesystem mount -u 681f2b5a-a1b2c3d4-1122-001122334455

Demontiranje:

esxcli storage filesystem unmount -l PROD-VMFS01

Demontiranje datastore-a je kontrolisana administrativna promena, a ne obična komanda za rešavanje problema. Pre toga mora se proveriti da datastore:

Kod trajnog uklanjanja LUN-a pravilni redosled obično uključuje migraciju ili uklanjanje potrošača, demontiranje datastore-a na svim hostovima, odvajanje uređaja, uklanjanje prezentacije sa storage strane i završni rescan. Preskakanje koraka može izazvati APD događaje, greške ili nekonzistentan prikaz storage-a.

APD i PDL stanja

Kod ozbiljnih storage prekida administrator može naići na izraze APD i PDL.

APD može biti posledica prekida mreže, fabric problema, restarta storage kontrolera ili drugih privremenih događaja. PDL se može javiti kada je LUN pogrešno uklonjen ili trajno povučen bez pravilne procedure.

Kod ovih stanja najvažnije je izbeći panične i destruktivne komande. Prvo se prikupljaju podaci iz vCenter događaja, vmkernel.log, stanja putanja i storage sistema, a zatim se odluke donose zajedno sa storage i mrežnim timom.

Logovi važni za datastore troubleshooting

Najvažniji ESXi log za veliki broj storage problema je:

/var/run/log/vmkernel.log

Pregled poslednjih poruka:

tail -n 100 /var/run/log/vmkernel.log

Praćenje novih poruka:

tail -f /var/run/log/vmkernel.log

Pretraga storage termina:

grep -Ei "APD|PDL|NMP|VMFS|I/O error|nfs|iscsi|scsi" \
/var/run/log/vmkernel.log | tail -n 100

Dodatno se proveravaju:

Metodologija za datastore troubleshooting

Dobar administrator ne počinje nasumičnim restartovanjem servisa i ponavljanjem rescan komandi. Najpre određuje obim problema.

1. Utvrditi šta je pogođeno

2. Utvrditi vrstu problema

3. Proveriti vremensku liniju

4. Uporediti hostove

Ako drugi hostovi normalno vide isti datastore, verovatnije je da je problem lokalizovan na host, HBA, VMkernel interfejs, mrežni uplink ili pojedinačnu putanju. Ako ga nijedan host ne vidi, analiza se širi na storage sistem, SAN fabric, NAS servis ili zajedničku mrežnu infrastrukturu.

5. Sačuvati dokaze pre promene

Pre restartovanja servisa, demontiranja datastore-a ili reboot-a hosta treba sačuvati:

Praktikum 1 – Inventar i mapiranje datastore infrastrukture

Cilj

Napraviti tačan inventar datastore-a, njihovih tipova, kapaciteta, slobodnog prostora, povezanih hostova i virtuelnih mašina.

Preduslovi

Korak 1 – Pregled kroz vSphere Client

  1. Otvoriti Menu → Storage.
  2. Zabeležiti ime, tip, kapacitet i slobodan prostor svakog datastore-a.
  3. Za svaki datastore otvoriti karticu Hosts.
  4. Proveriti da li ga vide svi očekivani hostovi.
  5. Otvoriti karticu VMs i zabeležiti broj VM-ova.
  6. Proveriti aktivne alarme i događaje.

Korak 2 – Pregled kroz PowerCLI

Connect-VIServer -Server vcsa.lab.local

Get-Datastore |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB,
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }} |
Sort-Object FreePercent

Korak 3 – Izvoz inventara

Get-Datastore |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB,
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }} |
Export-Csv "./vmware-datastores.csv" -NoTypeInformation

Korak 4 – Povezivanje VM-ova sa datastore-om

Get-Datastore -Name "PROD-VMFS01" |
Get-VM |
Select-Object Name, PowerState, VMHost

Očekivani rezultat

Administrator dobija dokumentovan pregled storage infrastrukture i može brzo da odgovori:

Administratorska provera

Ako jedan host ne vidi datastore koji vide ostali hostovi klastera, to treba evidentirati kao konfiguracioni ili operativni problem čak i ako trenutno nijedan VM nije pogođen.

Praktikum 2 – Kreiranje laboratorijskog VMFS datastore-a

Cilj

Kreirati novi VMFS datastore nad praznim laboratorijskim uređajem i proveriti njegovu dostupnost.

Važno upozorenje

Ova vežba sme se izvoditi isključivo nad praznim laboratorijskim diskom ili LUN-om. Kreiranje VMFS datastore-a formatira izabrani prostor i može uništiti postojeće podatke.

Preduslovi

Korak 1 – Identifikacija uređaja

esxcli storage core device list -c

Zabeležiti canonical naziv laboratorijskog uređaja, na primer:

naa.6000c29abcdef123456789000000001

Korak 2 – Kreiranje kroz vSphere Client

  1. Izabrati ESXi host.
  2. Otvoriti Storage → Datastores.
  3. Izabrati New datastore.
  4. Izabrati Create new VMFS datastore.
  5. Uneti naziv LAB-VMFS01.
  6. Pažljivo izabrati prethodno identifikovan prazan uređaj.
  7. Izabrati odgovarajuću VMFS verziju.
  8. Pregledati sažetak i potvrditi operaciju.

Korak 3 – Verifikacija kroz CLI

esxcli storage filesystem list
esxcli storage vmfs extent list
vmkfstools -P /vmfs/volumes/LAB-VMFS01

Korak 4 – Provera putanje

ls -l /vmfs/volumes
ls -lah /vmfs/volumes/LAB-VMFS01

Očekivani rezultat

Datastore LAB-VMFS01 prikazan je kao montiran, koristi VMFS i povezan je sa očekivanim storage uređajem.

Dodatni zadatak

Kreirati mali test VM na novom datastore-u, pokrenuti ga, a zatim proveriti da li se njegov folder i datoteke pojavljuju u Datastore Browser-u.

Praktikum 3 – Organizacija ISO repozitorijuma i kontrola sadržaja

Cilj

Napraviti uredan ISO repozitorijum, uploadovati instalacionu sliku, povezati je sa VM-om i proveriti da li je kasnije ostala nepotrebno priključena.

Korak 1 – Kreiranje direktorijuma

U Datastore Browser-u otvoriti datastore namenjen ISO sadržaju i kreirati strukturu:

ISO/
├── Linux/
├── Windows/
├── VMware-Tools/
└── Archived/

Korak 2 – Upload ISO slike

  1. Otvoriti odgovarajući direktorijum.
  2. Izabrati Upload.
  3. Odabrati laboratorijsku ISO sliku.
  4. Sačekati završetak zadatka.
  5. Proveriti veličinu uploadovanog fajla.

Korak 3 – Povezivanje sa VM-om

  1. Otvoriti Edit Settings test virtuelne mašine.
  2. Izabrati CD/DVD uređaj.
  3. Izabrati Datastore ISO File.
  4. Odabrati uploadovanu sliku.
  5. Uključiti Connect At Power On samo ako je potrebno.

Korak 4 – Provera VM konfiguracije

vim-cmd vmsvc/getallvms

Nakon utvrđivanja VMID-a:

vim-cmd vmsvc/device.getdevices VMID

Korak 5 – Čišćenje

Po završetku instalacije odvojiti ISO od VM-a. Pre brisanja stare ISO slike proveriti da li je ijedan VM još koristi.

Očekivani rezultat

ISO sadržaj je centralizovan, organizovan i kontrolisan. Administrator ne ostavlja nasumične ISO slike u folderima produkcionih VM-ova.

Praktikum 4 – Monitoring kapaciteta i alarm za nizak slobodan prostor

Cilj

Identifikovati datastore-e sa rizično niskim slobodnim prostorom i pripremiti izveštaj za kapacitivno planiranje.

Korak 1 – PowerCLI izveštaj

$report = Get-Datastore |
Where-Object { $_.CapacityGB -gt 0 } |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB,
              @{Name="UsedGB";Expression={
                  [math]::Round($_.CapacityGB - $_.FreeSpaceGB, 2)
              }},
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }}

$report | Sort-Object FreePercent | Format-Table -AutoSize

Korak 2 – Filtriranje kritičnih datastore-a

$report |
Where-Object { $_.FreePercent -lt 20 } |
Export-Csv "./datastore-capacity-warning.csv" -NoTypeInformation

Korak 3 – Kreiranje alarma

U vCenter Serveru pronaći datastore usage alarm ili kreirati odgovarajući alarm prema pravilima konkretnog okruženja. Pragove treba uskladiti sa veličinom datastore-a, stopom rasta, snapshot politikom i operativnim procedurama.

Primer organizacionih pragova:

Korak 4 – Analiza potrošača

Get-Datastore -Name "PROD-VMFS01" |
Get-VM |
Select-Object Name,
              PowerState,
              @{Name="ProvisionedGB";Expression={
                  [math]::Round($_.ProvisionedSpaceGB, 2)
              }},
              @{Name="UsedGB";Expression={
                  [math]::Round($_.UsedSpaceGB, 2)
              }} |
Sort-Object UsedGB -Descending

Očekivani rezultat

Administrator ima pregled rizika pre nego što datastore postane potpuno pun i može planirati čišćenje, migraciju ili proširenje kapaciteta.

Praktikum 5 – Storage vMotion test virtuelne mašine

Cilj

Premestiti datoteke test virtuelne mašine između dva datastore-a bez promene njenog compute hosta, ako okruženje podržava ovu funkcionalnost.

Preduslovi

Korak 1 – Početna provera

Get-VM -Name "LAB-APP01" |
Select-Object Name,
              VMHost,
              @{Name="Datastore";Expression={
                  (Get-Datastore -VM $_).Name -join ", "
              }}

Korak 2 – Migracija kroz vSphere Client

  1. Desni klik na test VM.
  2. Izabrati Migrate.
  3. Izabrati Change storage only.
  4. Izabrati odredišni datastore.
  5. Proveriti kompatibilnost.
  6. Pregledati sažetak i pokrenuti migraciju.
  7. Pratiti zadatak u Recent Tasks.

Korak 3 – PowerCLI varijanta

$vm = Get-VM -Name "LAB-APP01"
$targetDatastore = Get-Datastore -Name "LAB-VMFS02"

Move-VM -VM $vm -Datastore $targetDatastore

Korak 4 – Verifikacija

Get-VM -Name "LAB-APP01" |
Select-Object Name,
              PowerState,
              VMHost,
              @{Name="Datastore";Expression={
                  (Get-Datastore -VM $_).Name -join ", "
              }}

Proveriti i rad aplikacije ili operativnog sistema gosta tokom i nakon migracije.

Očekivani rezultat

VM ostaje dostupan, a njegove datoteke prelaze na odredišni datastore. Na izvornom datastore-u ne treba nasumično ručno brisati eventualne ostatke bez prethodne provere zadatka, logova i aktivnih referenci.

Praktikum 6 – Kontrolisana dijagnostika nestalog datastore-a

Cilj

Uvežbati redosled provera kada jedan ESXi host ne prikazuje datastore koji drugi hostovi i dalje vide.

Bezbednosno pravilo

Vežba se izvodi bez demontiranja produkcionog datastore-a i bez prekidanja aktivne putanje. Cilj je dijagnostički postupak, a ne namerno izazivanje incidenta.

Korak 1 – Uporediti hostove

Na pogođenom i zdravom hostu izvršiti:

esxcli storage filesystem list
esxcli storage vmfs extent list
esxcli storage core adapter list
esxcli storage core path list

Korak 2 – Proveriti uređaj

esxcli storage core device list -c

Utvrditi da li pogođeni host vidi isti canonical uređaj kao zdravi host.

Korak 3 – Proveriti logove

grep -Ei "APD|PDL|NMP|VMFS|I/O error|scsi" \
/var/run/log/vmkernel.log | tail -n 100

Korak 4 – Rescan, samo kada je opravdan

esxcli storage core adapter rescan --all

Korak 5 – Ponovna verifikacija

esxcli storage filesystem list
esxcli storage vmfs extent list

Korak 6 – Dokumentovanje

Zabeležiti:

Očekivani rezultat

Administrator može da razlikuje problem prezentacije uređaja, problem putanje, nemontiran filesystem i širi kvar storage sistema.

Scenario iz prakse 1 – Datastore je dostigao 100% kapaciteta

Simptomi

Prvi odgovor administratora

Ne treba odmah nasumično brisati velike VMDK ili delta datoteke. Prvo treba utvrditi šta je izazvalo rast.

esxcli storage filesystem list
vdf -h
ls -lah /vmfs/volumes/PROD-VMFS01

Zatim kroz vSphere Client i PowerCLI treba proveriti najveće VM potrošače, aktivne snapshot-e, backup zadatke, ISO slike i nedavne klonove.

Bezbedan redosled aktivnosti

  1. Potvrditi koji datastore je pun i koji VM-ovi su pogođeni.
  2. Zaustaviti ili odložiti nove zadatke koji dodatno troše prostor.
  3. Proveriti da li postoji bezbedan sadržaj za uklanjanje, na primer nepotrebne ISO slike ili provereno napuštene datoteke.
  4. Migrirati odgovarajuće VM-ove na drugi datastore ako postoji kapacitet.
  5. Proširiti datastore ako storage arhitektura i procedura to dozvoljavaju.
  6. Snapshot konsolidaciju izvoditi tek nakon procene potrebnog prostora i opterećenja.
  7. Pratiti VM i storage performanse tokom oporavka.

Šta ne treba raditi

Scenario iz prakse 2 – Datastore je vidljiv na dva hosta, ali nije vidljiv na trećem

Mogući uzroci

Dijagnostika

Na zdravom i pogođenom hostu uporediti:

esxcli storage core adapter list
esxcli storage core device list -c
esxcli storage core path list
esxcli storage vmfs extent list
esxcli storage filesystem list

Ako uređaj uopšte nije prikazan, problem je pre VMFS sloja. Treba proveriti storage prezentaciju, zoning, masking, iSCSI sesiju ili mrežnu dostupnost.

Ako je uređaj vidljiv, ali datastore nije montiran, proveravaju se UUID, mount status i vmkernel.log.

Zaključak incidenta

Rescan može pomoći tek kada je osnovna storage prezentacija ili mrežna komunikacija ispravna. Rescan ne može popraviti pogrešan zoning, nepostojeću iSCSI rutu ili NFS zabranu pristupa.

Scenario iz prakse 3 – Sve virtuelne mašine na jednom datastore-u rade sporo

Simptomi

Analiza

  1. Potvrditi da pogođeni VM-ovi dele isti datastore.
  2. Proveriti datastore performance grafikone.
  3. Pokrenuti esxtop i otvoriti storage prikaz.
  4. Proveriti stanje svih putanja.
  5. Proveriti da li je jedna putanja ostala aktivna umesto očekivanog multipath skupa.
  6. Proveriti storage array alarme, kontrolere, cache i backend diskove.
  7. Proveriti istovremene snapshot, backup, clone i Storage vMotion operacije.

Mogući nalaz

Jedna SAN putanja je otkazala, a preostala putanja je postala zasićena. VM-ovi nisu izgubili datastore, ali je ukupna propusnost smanjena i latencija povećana.

Ispravna reakcija

Ne treba restartovati sve VM-ove. Treba obnoviti redundansu storage putanja, smanjiti nepotrebno I/O opterećenje i pratiti povratak latencije na uobičajeni nivo.

Scenario iz prakse 4 – VM je uklonjen iz inventory-ja, ali njegove datoteke postoje

Situacija

Administrator je izabrao Remove from Inventory, a ne Delete from Disk. VM više nije prikazan u vCenter inventory-ju, ali njegov folder postoji na datastore-u.

Provera

ls -lah /vmfs/volumes/PROD-VMFS01/APP-SRV01

Treba potvrditi postojanje glavnog VMX fajla:

/vmfs/volumes/PROD-VMFS01/APP-SRV01/APP-SRV01.vmx

Oporavak kroz vSphere Client

  1. Otvoriti Datastore Browser.
  2. Pronaći folder VM-a.
  3. Izabrati odgovarajući .vmx fajl.
  4. Izabrati Register VM.
  5. Odabrati ime, folder, compute resurs i host ili klaster.
  6. Proveriti mreže, diskove i konfiguraciju pre pokretanja.

Važna provera

Pre registracije treba proveriti da ista virtuelna mašina nije već registrovana pod drugim imenom ili u drugom vCenter Serveru. Dvostruka registracija i pokušaj paralelnog pokretanja mogu izazvati zaključavanje datoteka i ozbiljne probleme.

Scenario iz prakse 5 – Datastore je posle restarta hosta prikazan kao nemontiran

Simptomi

Provera

esxcli storage core device list -c
esxcli storage vmfs extent list
esxcli storage filesystem list

Ako je potvrđeno da je to očekivani originalni datastore, nema konflikta sa resignature kopijom i storage putanje su stabilne, montiranje se može izvršiti prema labeli ili UUID-u:

esxcli storage filesystem mount -l PROD-VMFS01

Nakon toga:

esxcli storage filesystem list
vmkfstools -P /vmfs/volumes/PROD-VMFS01

Važna napomena

Ako ESXi prepoznaje uređaj kao snapshot kopiju VMFS volumena ili postoji više kopija sa istim potpisom, ne treba nasumično montirati ili resignature-ovati datastore. Prvo treba utvrditi poreklo LUN-a i namenu kopije.

Scenario iz prakse 6 – Storage vMotion ne može da premesti VM

Mogući simptomi

Redosled provere

  1. Pročitati punu poruku greške u Recent Tasks.
  2. Proveriti kapacitet odredišta.
  3. Proveriti kompatibilnost u migracionom čarobnjaku.
  4. Proveriti snapshot-e i zahtev za konsolidaciju.
  5. Proveriti storage politike i dostupnost datastore-a svim relevantnim hostovima.
  6. Proveriti vmware.log, hostd.log i vmkernel.log.
  7. Proveriti da li već postoji aktivna migracija, backup ili kloniranje.

Primer PowerCLI provere

$vm = Get-VM -Name "LAB-APP01"

$vm |
Select-Object Name,
              PowerState,
              VMHost,
              ProvisionedSpaceGB,
              UsedSpaceGB

Get-Snapshot -VM $vm

Get-Datastore -VM $vm |
Select-Object Name, CapacityGB, FreeSpaceGB

Pravilna reakcija

Uzrok se rešava pre ponovnog pokretanja migracije. Višestruko ponavljanje istog neuspešnog zadatka bez analize samo povećava broj događaja i može dodatno opteretiti infrastrukturu.

Najčešće administratorske greške

Administratorske prakse

Standardizovati nazive

Naziv datastore-a treba da prenese korisnu informaciju, na primer:

BG-DC1-PROD-VMFS01
BG-DC1-TEST-NFS01
BG-DC1-ISO-NFS01
BG-DC1-BACKUP-REPO01

Standard može sadržati lokaciju, namenu, tip storage-a i redni broj, ali treba izbegavati predugačke i nejasne nazive.

Održavati operativnu rezervu

Praktična rezerva zavisi od veličine datastore-a, rasta VM-ova, snapshot politike i vrste poslova. Fiksno pravilo nije dovoljno za svako okruženje, ali produkcioni datastore ne treba redovno održavati blizu punog kapaciteta.

Za VM-ove kod kojih se očekuju veliki snapshot-i ili intenzivne backup operacije treba planirati dodatni prostor. Broadcom preporuke za velike snapshot operacije naglašavaju potrebu za značajnom slobodnom rezervom, jer nedostatak prostora može izazvati neuspeh snapshot-a ili virtuelne mašine.

Pratiti trend, a ne samo trenutnu vrednost

Datastore sa 30% slobodnog prostora može biti rizičniji od datastore-a sa 15% ako prvi gubi nekoliko stotina gigabajta dnevno. Izveštaji treba da prikazuju:

Odvojiti različite namene kada je opravdano

Produkcioni VM-ovi, testni sistemi, ISO biblioteka i backup repozitorijum imaju različite obrasce korišćenja. Njihovo razdvajanje olakšava upravljanje kapacitetom, bezbednošću i performansama.

Dosledno proveravati pristup svih hostova

Novi datastore nije spreman za produkciju samo zato što ga vidi jedan host. U klasteru treba potvrditi da ga vide svi hostovi koji mogu pokretati odgovarajuće VM-ove.

Ne ignorisati degradiranu redundansu

Datastore može ostati dostupan nakon gubitka jedne putanje. To je degradirano, a ne zdravo stanje. Redundansu treba obnoviti pre sledećeg kvara ili planiranog održavanja.

Kontrolisati snapshot životni ciklus

Svaki snapshot treba da ima vlasnika, razlog, vreme kreiranja i plan uklanjanja. Automatski izveštaj o starim snapshot-ima treba da bude deo redovne administracije.

Get-VM |
Get-Snapshot |
Select-Object VM,
              Name,
              Created,
              SizeGB,
              Description |
Sort-Object Created

Dokumentovati zavisnosti

Za svaki važan datastore treba znati:

Koristiti maintenance i change procedure

Proširenje datastore-a, promena multipathing politike, uklanjanje LUN-a, izmena NFS export-a i firmware nadogradnja storage sistema predstavljaju promene koje mogu uticati na veliki broj VM-ova. Potrebni su plan, provera zavisnosti, rollback mogućnost i praćenje posle promene.

Razdvojiti monitoring kapaciteta i performansi

Kapacitet odgovara na pitanje „koliko prostora je ostalo”, dok performanse odgovaraju na pitanje „koliko brzo storage obrađuje zahteve”. Oba aspekta moraju imati posebne pragove, alarme i izveštaje.

Operativna kontrolna lista za datastore

Dnevna provera

Nedeljna provera

Mesečna provera

Najčešće korišćene ESXi CLI komande

# Lista filesystem-a i datastore-a
esxcli storage filesystem list

# VMFS datastore-i i njihovi uređaji
esxcli storage vmfs extent list

# Storage adapteri
esxcli storage core adapter list

# Rescan svih storage adaptera
esxcli storage core adapter rescan --all

# Storage uređaji
esxcli storage core device list
esxcli storage core device list -c

# Storage putanje
esxcli storage core path list

# Native Multipathing Plugin podaci
esxcli storage nmp device list

# Pregled datastore kapaciteta
vdf -h

# Datastore simboličke veze i UUID vrednosti
ls -l /vmfs/volumes

# Sadržaj određenog datastore-a
ls -lah /vmfs/volumes/PROD-VMFS01

# Karakteristike filesystem-a
vmkfstools -P /vmfs/volumes/PROD-VMFS01

# Lista registrovanih virtuelnih mašina
vim-cmd vmsvc/getallvms

# Montiranje datastore-a prema nazivu
esxcli storage filesystem mount -l PROD-VMFS01

# Montiranje datastore-a prema UUID-u
esxcli storage filesystem mount -u DATASTORE-UUID

# Demontiranje datastore-a
esxcli storage filesystem unmount -l PROD-VMFS01

# Storage logovi
tail -n 100 /var/run/log/vmkernel.log

# Praćenje loga uživo
tail -f /var/run/log/vmkernel.log

# Filtriranje čestih storage poruka
grep -Ei "APD|PDL|NMP|VMFS|I/O error|nfs|iscsi|scsi" \
/var/run/log/vmkernel.log | tail -n 100

# Interaktivno praćenje performansi
esxtop
# Zatim pritisnuti taster u za storage device prikaz

Najčešće korišćene PowerCLI komande

# Povezivanje sa vCenter Serverom
Connect-VIServer -Server vcsa.lab.local

# Svi datastore-i
Get-Datastore

# Datastore-i sortirani prema slobodnom prostoru
Get-Datastore |
Sort-Object FreeSpaceGB

# Kapacitet i procenat slobodnog prostora
Get-Datastore |
Select-Object Name,
              Type,
              CapacityGB,
              FreeSpaceGB,
              @{Name="FreePercent";Expression={
                  [math]::Round(($_.FreeSpaceGB / $_.CapacityGB) * 100, 2)
              }}

# Datastore-i sa manje od 20% slobodnog prostora
Get-Datastore |
Where-Object {
    $_.CapacityGB -gt 0 -and
    (($_.FreeSpaceGB / $_.CapacityGB) * 100) -lt 20
}

# VM-ovi na određenom datastore-u
Get-Datastore -Name "PROD-VMFS01" |
Get-VM

# Datastore-i koje koristi određeni VM
Get-VM -Name "APP-SRV01" |
Get-Datastore

# Snapshot-i svih VM-ova
Get-VM |
Get-Snapshot |
Select-Object VM, Name, Created, SizeGB

# Storage migracija test VM-a
Move-VM -VM "LAB-APP01" -Datastore "LAB-VMFS02"

# Izvoz datastore izveštaja
Get-Datastore |
Select-Object Name, Type, CapacityGB, FreeSpaceGB |
Export-Csv "./datastore-report.csv" -NoTypeInformation

# Prekid PowerCLI sesije
Disconnect-VIServer -Server vcsa.lab.local -Confirm:$false

Završna kontrolna tačka

Lekcija je završena kada administrator može dokazima da mapira datastore do njegovog uređaja ili mrežnog export-a, utvrdi hostove i VM-ove koji od njega zavise, izračuna kapacitivni rizik, razlikuje problem prostora od problema performansi i od gubitka putanje, bezbedno prikupi relevantne događaje i logove i objasni kada rescan, mount, unmount ili Storage vMotion menjaju stanje i zahtevaju change kontrolu i rollback plan.

Pitanja za proveru znanja

  1. Koja je razlika između fizičkog storage uređaja, LUN-a i datastore-a?
  2. Zašto više ESXi hostova može istovremeno pristupati VMFS datastore-u?
  3. Koja je osnovna razlika između VMFS i NFS datastore-a?
  4. Zašto lokalni datastore nije dovoljan za klasičan HA restart VM-a na drugom hostu?
  5. Šta prikazuje komanda esxcli storage filesystem list?
  6. Kako se VMFS datastore povezuje sa canonical nazivom storage uređaja?
  7. Zašto snapshot može da popuni datastore?
  8. Koja je razlika između APD i PDL stanja?
  9. Zašto izgubljena multipath putanja predstavlja problem i kada datastore i dalje radi?
  10. Koji log je najvažniji za veliki broj ESXi storage problema?
  11. Zašto ručno brisanje -delta.vmdk datoteke može uništiti VM?
  12. Koje provere treba izvršiti pre demontiranja datastore-a?
  13. Kako se kroz PowerCLI pronalaze datastore-i sa manje od 20% slobodnog prostora?
  14. Kako razlikovati problem jednog hosta od problema zajedničkog storage sistema?
  15. Zašto kapacitet i storage performanse moraju da se nadgledaju odvojeno?

Zaključak

Datastore je operativna osnova VMware infrastrukture. U njemu se ne čuvaju samo virtuelni diskovi, već i konfiguracija, stanje, snapshot lanci, swap datoteke, logovi i drugi elementi bez kojih virtuelna mašina ne može pravilno da radi.

Napredna administracija datastore-a zahteva više od provere slobodnog prostora. Administrator mora razumeti odnos između fizičkog storage-a, LUN-a ili NFS export-a, storage mreže, ESXi adaptera, putanja, VMFS ili NFS sloja i samih virtuelnih mašina. Tek takav pogled omogućava da se problem pravilno lokalizuje i da se izbegnu rizične intervencije.

Najvažnija praktična navika jeste određivanje obima incidenta pre bilo kakve promene: da li je pogođen jedan VM, jedan datastore, jedan host ili čitava storage infrastruktura. Nakon toga slede poređenje hostova, provera putanja, filesystem-a, kapaciteta, performansi i logova.

Stabilno VMware okruženje počiva na dobro dokumentovanim datastore-ima, kontrolisanom rastu kapaciteta, zdravim redundantnim putanjama, kratkotrajnom korišćenju snapshot-a, redovnom monitoringu i bezbednim change procedurama. Administrator koji ovlada tim postupcima može da reaguje pre nego što upozorenje preraste u prekid rada poslovnih servisa.

← Prethodna lekcija Povratak na sadržaj Sledeća lekcija →