VMware

Drugi deo: Napredna administracija zajedničke infrastrukture
Storage troubleshooting – kada datastore nestane, uspori ili se popuni
VI. Skladištenje, politike i integritet podataka
30. Storage troubleshooting – kapacitet, latencija, putanje i nedostupan datastore

Storage problem u VMware infrastrukturi retko ostaje ograničen samo na disk. Kada ESXi host izgubi pristup datastore-u, posledice se mogu pojaviti kao zamrznuta virtuelna mašina, neuspešan snapshot, nemogućnost pokretanja VM-a, usporena aplikacija, nedostupna konfiguraciona datoteka, prekid migracije ili host koji veoma sporo odgovara na zahteve vCenter servera.

Zbog toga storage troubleshooting ne počinje nasumičnim rescan-om, restartovanjem servisa ili promenom multipathing politike. Najpre se utvrđuje opseg incidenta, zatim storage sloj u kojem se problem nalazi, a tek nakon toga se izvodi kontrolisana korektivna radnja.

Administrator mora da odgovori na nekoliko osnovnih pitanja:

Najvažniji cilj nije da datastore što pre ponovo izgleda zeleno u vCenter-u, već da se pristup podacima obnovi bez dodatnog rizika, da se sačuvaju tragovi incidenta i da se utvrdi stvarni osnovni uzrok.

Lekcija je operativno usmerena na savremena vSphere 8.x okruženja i proverena je i prema aktuelnim Broadcom ESXCLI i VCF PowerCLI referencama. Nazivi pojedinih polja, alarma i menija mogu se razlikovati između tačkastih izdanja i klijentskih interfejsa, dok osnovni dijagnostički model — datastore, fajl sistem, uređaj, putanja, adapter i transport — ostaje isti. Pre izmene driver-a, firmware-a, SATP/PSP politike ili naprednih parametara obavezno se proveravaju matrica kompatibilnosti, release notes konkretnog build-a i dokumentacija proizvođača storage sistema.

Najčešće kategorije storage problema

Problemi se u praksi mogu grupisati u nekoliko osnovnih kategorija:

Prvo pravilo – utvrditi opseg incidenta

Opseg problema često odmah usmerava dijagnostiku.

Simptom Verovatniji sloj problema
Jedna virtuelna mašina je spora VMDK, guest OS, snapshot, pojedinačni workload ili VM konfiguracija
Sve VM na jednom datastore-u su spore Datastore, LUN, NFS export, storage pool ili zajedničke putanje
Svi datastore-i na jednom hostu su problematični HBA, NIC, VMkernel mreža, driver, firmware ili host konfiguracija
Isti datastore je nedostupan na svim hostovima Storage sistem, target, LUN prezentacija, NFS server ili fabric
Datastore je nedostupan samo na jednom hostu Lokalna putanja, adapter, VMkernel mreža, zoning ili host stanje
Svi hostovi vide samo polovinu putanja Otkaz fabric-a, switch-a, storage kontrolera ili target portova
VM-ovi ne mogu da se uključe zbog nedostatka prostora Popunjen datastore, snapshot rast, swap ili log datoteke

Drugo pravilo – utvrditi šta ESXi još uvek vidi

Datastore, fajl sistem, storage uređaj, adapter i putanja nisu isti objekat. Datastore može biti nedostupan iako uređaj još postoji. Uređaj može biti vidljiv, ali VMFS nije montiran. Adapter može biti online, ali bez putanje do konkretnog LUN-a.

Zbog toga se provera izvodi od višeg prema nižem sloju:

  1. datastore i fajl sistem;
  2. VMFS extent ili NFS mount;
  3. storage uređaj;
  4. putanje do uređaja;
  5. storage adapter;
  6. mrežni ili SAN transport;
  7. storage target, kontroler i fizički medij.

Početni CLI pregled

# pregled datastore-a i montiranih fajl sistema
esxcli storage filesystem list

# pregled VMFS datastore-a i pripadajućih uređaja
esxcli storage vmfs extent list

# pregled blokovskih storage uređaja
esxcli storage core device list

# pregled storage adaptera
esxcli storage core adapter list

# pregled svih storage putanja
esxcli storage core path list

# pregled NMP uređaja i politika
esxcli storage nmp device list

# pregled NFS 3 datastore-a
esxcli storage nfs list

# pregled NFS 4.1 datastore-a
esxcli storage nfs41 list

# pregled iSCSI adaptera
esxcli iscsi adapter list

# pregled aktivnih iSCSI sesija
esxcli iscsi session list

# pregled Fibre Channel adaptera
esxcli storage san fc list

Izlaz komandi treba sačuvati u incidentnoj dokumentaciji. Posebno su važni ime datastore-a, UUID, NAA identifikator uređaja, adapter, stanje putanja, politika izbora putanje i vreme kada je stanje zabeleženo.

Datastore je inaccessible

Status inaccessible znači da ESXi trenutno ne može da pristupi datastore-u. To ne znači automatski da su podaci obrisani ili da je fajl sistem oštećen. Uzrok može biti prekid mreže, gubitak svih putanja, uklonjena LUN prezentacija, NFS problem, administrativni unmount ili privremeno stanje storage kontrolera.

Prvo treba proveriti da li je datastore nedostupan na jednom ili na svim hostovima. 

esxcli storage filesystem list

Za VMFS datastore treba povezati ime datastore-a sa odgovarajućim uređajem: 

esxcli storage vmfs extent list

Nakon što se utvrdi NAA identifikator, proveravaju se uređaj i putanje: 

esxcli storage core device list \
  --device naa.ID_UREĐAJA
esxcli storage core path list \
  --device naa.ID_UREĐAJA

Ako uređaj postoji, ali VMFS nije montiran, problem nije isti kao kada uređaj uopšte nije vidljiv. Ne treba odmah kreirati novi datastore na uređaju koji sadrži postojeće podatke. Takva operacija može dovesti do gubitka postojeće strukture.

Datastore je unmounted

Datastore može biti administrativno demontiran, ali uređaj i dalje može biti priključen hostu. Pre pokušaja ponovnog montiranja treba proveriti zbog čega je datastore demontiran i da li je u toku planirana procedura uklanjanja.

Pregled poznatih VMFS volumena može se izvršiti komandama: 

esxcfg-volume -l
esxcli storage filesystem list

Ako se pronađe postojeći VMFS volume koji nije montiran, mora se utvrditi da li je to originalni volume, snapshot ili replika sa promenjenim potpisom. Ne treba nasumično koristiti mount, resignature ili force opcije bez razumevanja porekla uređaja.

Storage rescan – kada pomaže, a kada ne

Rescan nalaže ESXi hostu da ponovo proveri storage adaptere i otkrije nove ili promenjene uređaje. Koristan je nakon: 

esxcli storage core adapter rescan --all

Za pojedinačni adapter: 

esxcli storage core adapter rescan \
  --adapter vmhba64

Rescan ne popravlja neispravan kabl, pogrešan VLAN, uklonjenu LUN prezentaciju, nedostupan NFS server, neispravan storage kontroler ili pogrešno podešen MTU. Ako se uzrok ne otkloni, ponavljanje rescan-a samo proizvodi dodatne log poruke.

All Paths Down – APD

APD označava stanje u kojem ESXi nema nijednu dostupnu putanju do storage uređaja, ali nije dobio potvrdu da je uređaj trajno uklonjen. Host zato određeno vreme nastavlja da pokušava pristup i očekuje da se putanje možda oporave.

APD može nastati zbog:

Tokom APD stanja VM-ovi mogu postati neodzivni, hostd i vpxa servisi mogu sporo odgovarati, a operacije u vCenter-u mogu dugo čekati zato što I/O zahtevi ne dobijaju odgovor.

U podrazumevanoj APD obradi ESXi najpre čeka da se putanja oporavi; u aktuelnim vSphere 8.x referencama podrazumevani APD timeout je 140 sekundi. To nije obećanje da će se workload posle 140 sekundi automatski oporaviti: dalji odgovor zavisi od vrste datastore-a, stanja VM-a i vSphere HA podešavanja za datastore sa APD-om. HA reakcija i dodatni „delay for failure response” predstavljaju zasebnu klastersku politiku, koja se obrađuje u lekciji 32; tokom ovog incidenta najvažnije je ne prikriti kvar restartovanjem management agenata pre prikupljanja dokaza.

Provera APD stanja

grep -Ei "APD|All Paths Down|NMP|naa\." \
  /var/log/vmkernel.log |
  tail -n 200
esxcli storage core path list
esxcli storage core device list

Kod APD incidenta rešava se uzrok na storage, mrežnom ili SAN sloju. Host ne može softverskim rescan-om da obnovi putanju koja fizički ili logički ne postoji.

Permanent Device Loss – PDL

PDL označava da je ESXi dobio nedvosmislen odgovor da storage uređaj više nije dostupan tom hostu. Tipičan primer je kada je LUN mapping uklonjen sa storage sistema bez prethodne kontrolisane procedure na ESXi hostovima.

PDL se razlikuje od APD-a:

PDL može nastati zbog:

Provera PDL poruka

grep -Ei "PDL|Permanent Device Loss|PERM LOSS" \
  /var/log/vmkernel.log |
  tail -n 200

Ne treba pokušavati da se PDL rešava kreiranjem novog datastore-a na uređaju ili nasumičnim restartovanjem servisa. Najpre se proverava storage prezentacija i utvrđuje da li je uređaj uklonjen namerno ili greškom.

APD i PDL – praktično poređenje

Karakteristika APD PDL
Značenje Nijedna putanja trenutno nije dostupna Uređaj je potvrđeno trajno nedostupan
Da li uređaj možda još postoji? Da Storage ga više ne prezentuje hostu
Tipičan uzrok Mreža, fabric, target ili kontroler Uklonjen mapping ili LUN
Osnovna reakcija Obnoviti storage putanju Potvrditi nameru i prezentaciju uređaja
Rizik Dugotrajno čekanje I/O operacija VM i datastore ostaju bez uređaja

Path redundancy degraded

Gubitak jedne storage putanje ne mora odmah prekinuti rad virtuelnih mašina. Ako druge putanje rade, I/O se nastavlja, ali infrastruktura više nema punu redundansu.

Takav alarm ne treba ignorisati zato što „sve još radi”. Sledeći kvar može ukloniti i poslednju dostupnu putanju. 

esxcli storage core path list \
  --device naa.ID_UREĐAJA
esxcli storage nmp device list \
  --device naa.ID_UREĐAJA

Potrebno je utvrditi:

NFS datastore troubleshooting

Kod NFS-a ESXi zavisi od VMkernel mreže, IP dostupnosti NFS servera, export dozvola, verzije protokola i ispravnog identiteta udaljenog servera.

Posebno kod NFS 4.1 nije dovoljno pretpostaviti da će saobraćaj uvek koristiti VMkernel adapter koji administrator smatra „NFS adapterom”. Izbor izvorišne adrese zavisi od VMkernel TCP/IP steka i rutiranja; ako je server u drugoj mreži, zahtev može otići sa management adrese i biti odbijen export politikom. Zato se zajedno proveravaju ruta, stvarna izvorišna VMkernel adresa, dozvole na serveru i, kada je potrebno, paketni trag — ne samo uspešan ping.

Pregled NFS 3 datastore-a

esxcli storage nfs list

Pregled NFS 4.1 datastore-a

esxcli storage nfs41 list

U izlazu treba proveriti:

Provera VMkernel mreže

esxcli network ip interface list
esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list

Testiranje NFS servera sa odgovarajućeg VMkernel adaptera

vmkping -I vmk2 192.168.30.20

Testiranje jumbo frame putanje

vmkping -I vmk2 -d -s 8972 192.168.30.20

Ako običan test prolazi, a test sa velikim paketom i zabranjenom fragmentacijom ne prolazi, moguće je da MTU nije dosledno podešen na ESXi hostu, fizičkom switch-u ili storage uređaju.

Provera ESXi firewall pravila

esxcli network firewall ruleset list |
  grep -i nfs

Provera NFS log poruka

grep -Ei "NFS|SunRPC|mount|APD" \
  /var/log/vmkernel.log |
  tail -n 200

Najčešći NFS uzroci su:

iSCSI troubleshooting

iSCSI problem može postojati na više nivoa: VMkernel mreža, physical NIC, VLAN, port binding, target discovery, CHAP autentifikacija, iSCSI sesija, LUN masking ili sam storage uređaj.

Pregled iSCSI adaptera

esxcli iscsi adapter list

Detalji adaptera

esxcli iscsi adapter get \
  --adapter vmhba64

Pregled discovery portala

esxcli iscsi adapter discovery sendtarget list \
  --adapter vmhba64

Pregled iSCSI target-a

esxcli iscsi adapter target list \
  --adapter vmhba64

Pregled aktivnih sesija

esxcli iscsi session list

Pregled port binding-a

esxcli iscsi networkportal list \
  --adapter vmhba64

Testiranje target adresa

vmkping -I vmk2 192.168.40.20
vmkping -I vmk3 192.168.41.20

Pregled fizičkog mrežnog adaptera

esxcli network nic list
esxcli network nic stats get \
  --nic-name vmnic4

Posebno treba obratiti pažnju na:

Uspešan vmkping potvrđuje osnovnu IP dostupnost, ali ne dokazuje da TCP port 3260, iSCSI autentifikacija, target discovery i LUN masking rade ispravno.

Fibre Channel troubleshooting

Kod Fibre Channel-a putanja obuhvata HBA adapter, optički modul, kabl, FC switch port, zoning, storage target port, storage kontroler i LUN masking.

Pregled FC adaptera

esxcli storage san fc list

Treba proveriti:

Pregled FC statistike

esxcli storage san fc stats get \
  --adapter vmhba2

Pregled FC događaja

esxcli storage san fc events get \
  --adapter vmhba2

Pregled uređaja koje vidi adapter

esxcli storage core adapter device list \
  --adapter vmhba2

Ako je jedan FC adapter online, a drugi ne vidi uređaje, proveravaju se:

Datastore je spor

Spor datastore se ne dijagnostikuje samo subjektivnim utiskom korisnika. Potrebno je meriti IOPS, throughput, queue vrednosti i latenciju na ESXi hostu, a zatim podatke uporediti sa storage sistemom i mrežnom ili SAN infrastrukturom.

Problem može biti:

Storage latencija u esxtop alatu

esxtop

Nakon pokretanja:

Najvažnije kolone u device prikazu su:

Približno važi: 

GAVG ≈ DAVG + KAVG

Visok DAVG češće usmerava analizu prema storage sistemu, target portu, mreži ili SAN fabric-u. Visok KAVG može ukazivati na queuing i zadržavanje zahteva u ESXi hostu. Visok GAVG pokazuje ukupno kašnjenje koje dobija virtuelna mašina.

Vrednosti ne treba tumačiti izolovano niti koristiti jednu univerzalnu granicu za sve aplikacije. Važno je poređenje sa:

Praćenje pojedinačnog VMDK-a

Kada je problem vezan za jednu virtuelnu mašinu, u alatu esxtop može se koristiti prikaz virtuelnih diskova:

  1. pokrenuti esxtop;
  2. pritisnuti v;
  3. pronaći GID virtuelne mašine;
  4. pritisnuti e;
  5. uneti GID radi filtriranja prikaza.

Time se proverava da li je latencija vezana za jedan VMDK, jednu virtuelnu mašinu ili širi storage problem.

Queue problemi

Storage uređaj može biti zdrav, ali I/O zahtevi mogu čekati zato što je queue zasićen. Queue dubina postoji na više nivoa:

Queue vrednosti ne treba menjati bez vendor preporuke. Povećavanje queue depth-a može samo premestiti problem na storage sistem i povećati latenciju za druge hostove.

Datastore je skoro popunjen

Popunjen datastore nije samo problem kapaciteta. Može sprečiti:

Pregled kapaciteta datastore-a

esxcli storage filesystem list

Pregled preko PowerCLI-ja: 

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

Najčešći potrošači prostora

Pregled velikih datoteka

Na ESXi hostu može se pregledati sadržaj konkretnog direktorijuma: 

cd /vmfs/volumes/IME_DATASTOREA/IME_VM_DIREKTORIJUMA
ls -lh

Za pregled zauzeća direktorijuma: 

du -h -d 1 /vmfs/volumes/IME_DATASTOREA

Ove komande treba koristiti pažljivo na velikim datastore-ima. Rekurzivno pretraživanje velikog broja datoteka može stvoriti dodatno opterećenje.

Snapshot rast i popunjen datastore

Snapshot ne predstavlja potpunu kopiju virtuelne mašine. Nakon kreiranja snapshot-a novi upisi se usmeravaju u delta datoteke, koje mogu rasti dok ne dostignu značajan deo kapaciteta osnovnog diska.

Snapshot može postati veliki zbog:

Pregled snapshot-a preko PowerCLI-ja

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

Pronalaženje starijih snapshot-a

Get-VM |
  Get-Snapshot |
  Where-Object {
    $_.Created -lt (Get-Date).AddDays(-3)
  } |
  Select-Object VM,
                Name,
                Created,
                SizeGB

Snapshot se ne uklanja ručnim brisanjem -delta.vmdk, -sesparse.vmdk ili drugih datoteka iz datastore-a. Uklanjanje i konsolidacija izvode se kroz vSphere mehanizme.

Thin provisioning i datastore kapacitet

Thin VMDK u početku zauzima manje fizičkog prostora od svog deklarisanog kapaciteta. Kako guest upisuje podatke, VMDK raste. Ako je zbir mogućeg rasta svih thin diskova veći od fizičkog kapaciteta datastore-a, postoji rizik od overcommit-a.

Administrator mora pratiti:

VMFS datastore ne vidi isti kapacitet na svim hostovima

Nakon proširenja LUN-a storage sistem može prikazati novi kapacitet, ali pojedini hostovi još mogu videti staru veličinu. Potrebno je:

  1. potvrditi da je LUN proširen na storage sistemu;
  2. proveriti da je promena primenjena na sve host grupe;
  3. izvršiti rescan na svim relevantnim hostovima;
  4. proveriti novu veličinu uređaja;
  5. tek zatim proširiti VMFS datastore kroz podržani postupak.
esxcli storage core device list \
  --device naa.ID_UREĐAJA

Ne treba proširivati VMFS dok svi hostovi ne vide ispravan uređaj i očekivanu veličinu.

Virtuelna mašina je inaccessible ili Unknown

Ako ESXi ne može da pročita .vmx datoteku virtuelne mašine, vCenter može prikazati VM kao inaccessible ili Unknown. To često nije problem same VM registracije, već posledica nedostupnog datastore-a.

Pre uklanjanja VM-a iz inventory-ja treba proveriti:

Važne log datoteke

Log Najvažnija namena
/var/log/vmkernel.log Storage putanje, adapteri, SCSI greške, APD, PDL, NFS i latencija
/var/log/vobd.log Storage i hardverska upozorenja i observations
/var/log/hostd.log Host management operacije i datastore zadaci
/var/log/vpxa.log Komunikacija hosta sa vCenter serverom
/var/log/fdm.log vSphere HA i datastore heartbeat događaji
vmware.log u VM direktorijumu Problemi konkretne virtuelne mašine i virtuelnih diskova

Efikasna pretraga logova

grep -Ei "APD|PDL|NFS|iSCSI|naa\.|vmhba|I/O error|latency" \
  /var/log/vmkernel.log |
  tail -n 200

Za praćenje novih događaja u realnom vremenu: 

tail -f /var/log/vmkernel.log

Logove treba povezati sa tačnim vremenom incidenta. Vreme na ESXi hostovima, vCenter serveru, storage sistemu i mrežnim uređajima mora biti sinhronizovano kako bi se događaji mogli pravilno uporediti.

Šta ne treba raditi tokom storage incidenta

Praktikum – početno evidentiranje stanja

Pre bilo kakve korektivne radnje treba zabeležiti početno stanje. Cilj je da administrator može da odgovori šta je bilo vidljivo pre promene, šta se promenilo i da li je oporavak zaista potpun.

Topologija, preduslovi i granice rizika

Read-only komande u ovom praktikumu mogu se bezbedno izvršavati u produkciji uz uobičajenu kontrolu pristupa. Rescan menja stanje otkrivanja uređaja i izvodi se tek kada je osnovni transportni ili prezentacioni uzrok otklonjen. Prekid putanje, uklanjanje LUN mapping-a, gašenje NFS servisa, resignature, detach i ručno brisanje datoteka nisu dozvoljene produkcione simulacije. U laboratoriji se degraded-path stanje bezbednije demonstrira administrativnim isključivanjem samo jedne redundantne test putanje, uz potvrđenu drugu putanju i unapred definisan rollback.

Kriterijum početnog stanja

Pre simulacije moraju biti zabeleženi naziv i UUID datastore-a, NAA identifikator ili NFS server/export, očekivani broj putanja, SATP/PSP, adapteri, slobodan prostor i početne vrednosti latencije. Laboratorija se smatra vraćenom u početno stanje tek kada se svi ti podaci ponovo podudaraju, nema novih APD/PDL događaja, a testna VM uspešno čita i upisuje podatke.

Korak 1 – evidentirati datastore-e

esxcli storage filesystem list

Korak 2 – povezati VMFS datastore-e sa uređajima

esxcli storage vmfs extent list

Korak 3 – evidentirati uređaje

esxcli storage core device list

Korak 4 – evidentirati putanje

esxcli storage core path list

Korak 5 – proveriti multipathing politiku

esxcli storage nmp device list

Korak 6 – evidentirati adaptere

esxcli storage core adapter list

Korak 7 – sačuvati relevantne logove

cp /var/log/vmkernel.log \
  /tmp/vmkernel-storage-incident.log
cp /var/log/vobd.log \
  /tmp/vobd-storage-incident.log

U produkciji treba koristiti zvanični support bundle i centralizovano čuvanje logova, ali lokalne kopije mogu pomoći da se sačuva neposredni trag događaja.

Scenario 1 – datastore je nedostupan samo na jednom hostu

U klasteru sa četiri ESXi hosta isti VMFS datastore radi na tri hosta, dok je na četvrtom prikazan kao inaccessible.

Zaključak iz opsega problema

Pošto storage radi na ostalim hostovima, verovatnije je da je problem vezan za pogođeni host, njegov adapter, mrežnu ili FC putanju, zoning, port binding ili lokalno stanje uređaja.

Korak 1 – proveriti datastore i uređaj

esxcli storage filesystem list
esxcli storage vmfs extent list

Korak 2 – proveriti putanje uređaja

esxcli storage core path list \
  --device naa.ID_UREĐAJA

Korak 3 – uporediti sa zdravim hostom

Iste komande treba izvršiti na jednom zdravom hostu i uporediti:

Korak 4 – proveriti adapter

Za iSCSI: 

esxcli iscsi session list
esxcli iscsi networkportal list \
  --adapter vmhba64

Za Fibre Channel: 

esxcli storage san fc list
esxcli storage core adapter device list \
  --adapter vmhba2

Korak 5 – pregledati log

grep -Ei "APD|PDL|naa\.|vmhba|NMP" \
  /var/log/vmkernel.log |
  tail -n 200

Korak 6 – nakon otklanjanja uzroka izvršiti rescan

esxcli storage core adapter rescan --all

Potvrda oporavka

Scenario 2 – datastore je nedostupan na svim hostovima

Svi hostovi u klasteru istovremeno gube pristup istom datastore-u.

Zaključak iz opsega problema

Kada isti datastore nestane sa svih hostova, verovatniji uzrok je na zajedničkom sloju:

Korak 1 – proveriti da li postoji uređaj

esxcli storage core device list

Korak 2 – proveriti putanje

esxcli storage core path list \
  --device naa.ID_UREĐAJA

Korak 3 – proveriti APD i PDL događaje

grep -Ei "APD|PDL|PERM LOSS|All Paths Down" \
  /var/log/vmkernel.log |
  tail -n 200

Korak 4 – proveriti storage tim i promene

Potrebno je potvrditi:

Korak 5 – obnoviti zajednički uzrok

Tek nakon obnove storage, mrežnog ili SAN sloja izvršava se rescan na pogođenim hostovima. 

esxcli storage core adapter rescan --all

Važna mera opreza

Ne treba istovremeno restartovati sve hostove klastera. Oporavak se izvodi kontrolisano, uz potvrdu stanja storage-a i očuvanje kapaciteta za preostale workload-e.

Scenario 3 – NFS datastore je inaccessible

NFS datastore je vidljiv u inventory-ju, ali nije dostupan. Drugi datastore-i rade normalno.

Korak 1 – proveriti mount stanje

esxcli storage nfs list

Za NFS 4.1: 

esxcli storage nfs41 list

Korak 2 – proveriti VMkernel adresu i routing

esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list

Korak 3 – testirati NFS server

vmkping -I vmk2 192.168.30.20

Korak 4 – proveriti MTU

vmkping -I vmk2 -d -s 8972 192.168.30.20

Korak 5 – pregledati mrežni adapter

esxcli network nic stats get \
  --nic-name vmnic4

Korak 6 – pregledati log

grep -Ei "NFS|SunRPC|APD|mount" \
  /var/log/vmkernel.log |
  tail -n 200

Korak 7 – proveriti storage stranu

Potvrda oporavka

esxcli storage nfs list
esxcli storage filesystem list

Nakon obnove pristupa proveravaju se virtuelne mašine koje koriste datastore, jer neke mogu ostati u stanju koje zahteva dodatnu proveru ili registraciju.

Scenario 4 – iSCSI target odgovara na ping, ali LUN nije vidljiv

VMkernel adapter može da ping-uje iSCSI target, ali ESXi ne prikazuje očekivani uređaj.

Korak 1 – proveriti adapter

esxcli iscsi adapter list

Korak 2 – proveriti discovery portal

esxcli iscsi adapter discovery sendtarget list \
  --adapter vmhba64

Korak 3 – proveriti target

esxcli iscsi adapter target list \
  --adapter vmhba64

Korak 4 – proveriti sesije

esxcli iscsi session list

Ako nema sesije, proveravaju se:

Ako sesija postoji, ali LUN nije vidljiv, proveravaju se:

Korak 5 – izvršiti kontrolisani rescan

esxcli storage core adapter rescan \
  --adapter vmhba64

Korak 6 – proveriti uređaje

esxcli storage core adapter device list \
  --adapter vmhba64

Korak 7 – proveriti putanje

esxcli storage core path list

Scenario 5 – Fibre Channel LUN ima samo jednu putanju

LUN je dostupan, ali ESXi prikazuje samo jednu putanju umesto očekivanih četiri.

Korak 1 – proveriti HBA adaptere

esxcli storage san fc list

Korak 2 – proveriti uređaje po adapteru

esxcli storage core adapter device list \
  --adapter vmhba2
esxcli storage core adapter device list \
  --adapter vmhba3

Korak 3 – proveriti putanje konkretnog LUN-a

esxcli storage core path list \
  --device naa.ID_UREĐAJA

Korak 4 – proveriti FC statistiku

esxcli storage san fc stats get \
  --adapter vmhba2
esxcli storage san fc stats get \
  --adapter vmhba3

Korak 5 – proveriti SAN sloj

Korak 6 – nakon ispravke izvršiti rescan

esxcli storage core adapter rescan \
  --adapter vmhba2
esxcli storage core adapter rescan \
  --adapter vmhba3

Potvrda oporavka

Potrebno je potvrditi ne samo broj putanja već i da one prolaze kroz očekivane nezavisne fabric-e, HBA adaptere, target portove i storage kontrolere.

Scenario 6 – virtuelne mašine su spore, ali CPU i memorija nisu opterećeni

Korisnici prijavljuju spor rad aplikacije. CPU ready, potrošnja memorije i mreža ne pokazuju ozbiljno zagušenje.

Korak 1 – pokrenuti esxtop

esxtop

Pritisnuti u i pratiti:

Korak 2 – izolovati VM ili VMDK

U alatu esxtop pritisnuti v, pronaći VM i filtrirati njen GID.

Korak 3 – proveriti putanje

esxcli storage core path list \
  --device naa.ID_UREĐAJA

Korak 4 – proveriti mrežne greške za NFS ili iSCSI

esxcli network nic stats get \
  --nic-name vmnic4

Korak 5 – proveriti storage log

grep -Ei "latency|performance has deteriorated|I/O|naa\." \
  /var/log/vmkernel.log |
  tail -n 200

Korak 6 – uporediti sa storage sistemom

Za isti vremenski interval treba prikupiti:

Tumačenje

Scenario 7 – datastore je popunjen zbog snapshot-a

Datastore je dostigao kritičan nivo, a pregled pokazuje velike snapshot delta datoteke.

Korak 1 – proveriti slobodan prostor

esxcli storage filesystem list

Korak 2 – pregledati snapshot-e

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

Korak 3 – identifikovati razlog snapshot-a

Korak 4 – obezbediti prostor pre konsolidacije

Moguće bezbedne mere, u zavisnosti od okruženja, uključuju:

Korak 5 – ukloniti snapshot kroz vSphere

Snapshot datoteke se ne brišu ručno. Uklanjanje se izvodi kroz Snapshot Manager, PowerCLI ili odgovarajući vSphere API postupak.

Korak 6 – pratiti prostor i latenciju

Konsolidacija može generisati značajan I/O. Tokom operacije treba pratiti:

Scenario 8 – datastore je potpuno popunjen

Datastore više nema raspoloživ prostor, pojedine VM su pauzirane ili ne mogu da izvršavaju upis.

Prvi cilj – zaustaviti dalji rast

Drugi cilj – bezbedno osloboditi ili dodati kapacitet

Prioritet imaju mere koje ne ugrožavaju VM datoteke:

Šta ne raditi

Scenario 9 – VMFS datastore se ne pojavljuje nakon rescan-a

ESXi vidi uređaj, ali postojeći VMFS datastore nije automatski montiran.

Korak 1 – potvrditi uređaj

esxcli storage core device list \
  --device naa.ID_UREĐAJA

Korak 2 – pregledati VMFS extent-e

esxcli storage vmfs extent list

Korak 3 – pregledati nemontirane VMFS volumene

esxcfg-volume -l

Korak 4 – utvrditi poreklo uređaja

Potrebno je proveriti da li je uređaj:

Mount i resignature imaju različite posledice. Odluka se donosi tek nakon potvrde porekla uređaja i namene kopije.

Scenario 10 – datastore je uklonjen bez pravilne procedure

Storage administrator je uklonio LUN mapping pre nego što je datastore demontiran i uređaj detached sa ESXi hostova.

Mogući simptomi

Postupak

  1. Utvrditi da li je uklanjanje bilo namerno.
  2. Proveriti da li na datastore-u postoje potrebne VM ili druge datoteke.
  3. Ako je uklanjanje bilo greška, obnoviti LUN prezentaciju sa istim identitetom.
  4. Ako je uklanjanje bilo namerno, očistiti zavisnosti prema podržanoj proceduri.
  5. Proveriti datastore heartbeat, ISO veze i registrovane VM-ove.
  6. Izvršiti kontrolisani rescan.
  7. Proveriti da li su stari uređaji i reference uklonjeni.

Bezbedna procedura uklanjanja VMFS datastore-a

  1. Identifikovati sve VM-ove i datoteke na datastore-u.
  2. Migrirati ili ugasiti zavisne virtuelne mašine.
  3. Odvojiti ISO slike povezane sa VM-ovima.
  4. Proveriti template-e, swap datoteke i dump lokacije.
  5. Proveriti vSphere HA datastore heartbeat konfiguraciju.
  6. Proveriti Storage DRS i datastore cluster članstvo.
  7. Demontirati datastore sa svih hostova.
  8. Detach-ovati uređaj sa svih hostova kada je primenljivo.
  9. Tek zatim ukloniti LUN mapping ili storage objekat.
  10. Izvršiti rescan i potvrditi uklanjanje.
  11. Ažurirati dokumentaciju i monitoring.

PowerCLI pregled datastore kapaciteta

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

Pronalaženje datastore-a sa manje od 15% slobodnog prostora

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

Pregled datastore-a po ESXi hostovima

Get-Cluster -Name "PROD-CLUSTER" |
  Get-VMHost |
  ForEach-Object {
    $VMHost = $_

    Get-Datastore -VMHost $VMHost |
      Select-Object @{
        Name = "VMHost"
        Expression = { $VMHost.Name }
      },
      Name,
      Type,
      CapacityGB,
      FreeSpaceGB
  }

Poređenje storage uređaja i multipathing politika

Get-Cluster -Name "PROD-CLUSTER" |
  Get-VMHost |
  ForEach-Object {
    $VMHost = $_

    Get-ScsiLun -VMHost $VMHost -LunType disk |
      Select-Object @{
        Name = "VMHost"
        Expression = { $VMHost.Name }
      },
      CanonicalName,
      Vendor,
      Model,
      CapacityGB,
      MultipathPolicy,
      OperationalState
  }

Pregled storage putanja kroz PowerCLI

Get-Cluster -Name "PROD-CLUSTER" |
  Get-VMHost |
  ForEach-Object {
    $VMHost = $_

    Get-ScsiLun -VMHost $VMHost -LunType disk |
      Get-ScsiLunPath |
      Select-Object @{
        Name = "VMHost"
        Expression = { $VMHost.Name }
      },
      Name,
      State,
      SanId,
      ScsiLun
  }

Operativna procedura za visoku latenciju

  1. Zabeležiti tačno vreme problema.
  2. Utvrditi pogođene VM-ove, hostove i datastore-e.
  3. Prikupiti esxtop podatke.
  4. Utvrditi DAVG, KAVG, GAVG i QAVG.
  5. Proveriti storage putanje.
  6. Proveriti adapter greške.
  7. Proveriti mrežne ili FC switch portove.
  8. Prikupiti array statistiku za isti period.
  9. Proveriti backup, snapshot, replikaciju i maintenance procese.
  10. Uporediti stanje sa normalnim baznim vrednostima.
  11. Otkloniti uzrok na odgovarajućem sloju.
  12. Ponoviti merenje nakon korekcije.

Operativna procedura za gubitak putanje

  1. Utvrditi koji uređaj i datastore su pogođeni.
  2. Utvrditi broj preostalih aktivnih putanja.
  3. Proveriti da li je problem na jednom ili svim hostovima.
  4. Identifikovati adapter, fabric, switch i target port.
  5. Proveriti da li preostala putanja ima dovoljno kapaciteta.
  6. Otkloniti fizički ili konfiguracioni uzrok.
  7. Izvršiti rescan tek nakon korekcije.
  8. Potvrditi vraćanje svih očekivanih putanja.
  9. Proveriti latenciju nakon oporavka.
  10. Zabeležiti osnovni uzrok i preventivnu meru.

Operativna procedura za datastore sa malo prostora

  1. Potvrditi trenutni slobodan prostor.
  2. Utvrditi brzinu trošenja prostora.
  3. Identifikovati najveće potrošače.
  4. Proveriti snapshot-e i backup poslove.
  5. Zaustaviti nepotrebno dodatno zauzeće.
  6. Obezbediti novi kapacitet ili migrirati workload.
  7. Kontrolisano ukloniti nepotrebne podatke.
  8. Potvrditi da su VM-ovi stabilni.
  9. Podesiti ili korigovati alarme.
  10. Dokumentovati razlog zbog kog alarm nije ranije sprečio incident.

Administratorske prakse

Kontrolna lista – datastore je nestao

  1. Utvrđen je opseg incidenta.
  2. Provereno je stanje na drugim hostovima.
  3. Datastore je povezan sa NFS export-om ili NAA uređajem.
  4. Proveren je storage adapter.
  5. Proverene su sve putanje.
  6. Provereni su APD i PDL događaji.
  7. Proverene su mrežne ili FC veze.
  8. Proverena je storage prezentacija.
  9. Sačuvani su logovi.
  10. Uzrok je otklonjen pre rescan-a.
  11. Potvrđen je povratak svih putanja.
  12. Proveren je rad virtuelnih mašina.

Kontrolna lista – datastore je spor

  1. Zabeleženo je tačno vreme problema.
  2. Utvrđeno je da li je pogođena jedna VM ili više njih.
  3. Prikupljene su DAVG, KAVG, GAVG i QAVG vrednosti.
  4. Proverene su putanje i multipathing politika.
  5. Proverene su NIC ili HBA greške.
  6. Provereni su switch portovi.
  7. Provereni su storage kontroleri i target portovi.
  8. Provereni su snapshot i backup procesi.
  9. Vrednosti su upoređene sa baznim stanjem.
  10. Nakon korekcije ponovljeno je merenje.

Kontrolna lista – datastore je skoro popunjen

  1. Potvrđen je stvarni kapacitet i slobodan prostor.
  2. Utvrđena je brzina rasta zauzeća.
  3. Identifikovani su najveći direktorijumi i VM-ovi.
  4. Provereni su snapshot-i.
  5. Provereni su aktivni backup poslovi.
  6. Zaustavljeno je nepotrebno dodatno zauzeće.
  7. Obezbeđen je prostor za eventualnu konsolidaciju.
  8. Kapacitet je proširen ili je workload migriran.
  9. Potvrđen je normalan rad VM-ova.
  10. Korigovani su alarmi i planiranje kapaciteta.

Završna kontrolna tačka

Lekcija je savladana kada administrator može da demonstrira sledeće proverljive sposobnosti bez nasumičnih promena produkcionog stanja:

Pitanja za proveru znanja

  1. Zašto inaccessible datastore ne znači automatski da su podaci izgubljeni?
  2. Koja komanda povezuje VMFS datastore sa NAA uređajem?
  3. Koja je razlika između storage uređaja, putanje i datastore-a?
  4. Kada storage rescan može pomoći?
  5. Zašto rescan ne rešava neispravan VLAN ili uklonjenu LUN prezentaciju?
  6. Koja je osnovna razlika između APD i PDL stanja?
  7. Zašto gubitak jedne putanje zahteva reakciju iako VM-ovi još rade?
  8. Koje komande se koriste za proveru NFS 3 i NFS 4.1 datastore-a?
  9. Zašto uspešan vmkping nije dovoljan dokaz da iSCSI radi?
  10. Koji slojevi učestvuju u Fibre Channel putanji?
  11. Šta predstavljaju DAVG, KAVG i GAVG vrednosti?
  12. Kako se u esxtop alatu prati pojedinačni VMDK?
  13. Zašto queue depth ne treba povećavati bez vendor preporuke?
  14. Koje datoteke najčešće popunjavaju datastore?
  15. Zašto se snapshot delta datoteke ne smeju ručno brisati?
  16. Kako thin provisioning može dovesti do popunjavanja datastore-a?
  17. Zašto se LUN ne uklanja sa storage sistema pre unmount i detach procedure?
  18. Koje podatke treba prikupiti pre restartovanja hosta tokom incidenta?
  19. Zašto je sinhronizacija vremena važna za troubleshooting?
  20. Kako se potvrđuje da je storage incident zaista završen?

Zaključak

Storage troubleshooting u VMware okruženju zahteva sistematičan rad kroz više povezanih slojeva. Datastore koji je nestao iz vCenter prikaza može i dalje imati vidljiv uređaj, uređaj može imati izgubljene putanje, a putanja može biti prekinuta na hostu, mrežnom switch-u, SAN fabric-u, target portu ili storage kontroleru. Zbog toga se problem ne rešava jednom univerzalnom komandom.

Kada datastore postane nedostupan, prvo se utvrđuje opseg incidenta, zatim se datastore povezuje sa odgovarajućim NFS export-om ili NAA uređajem, proveravaju se putanje, adapteri i transport, a potom i storage prezentacija. Razlikovanje APD i PDL stanja posebno je važno jer jedno označava privremeni gubitak svih putanja, dok drugo označava da je uređaj potvrđeno uklonjen iz pristupa hosta.

Kada je datastore spor, administrator mora da meri, a ne da nagađa. DAVG, KAVG, GAVG i queue pokazatelji pomažu da se kašnjenje razdvoji između storage uređaja, spoljne putanje i ESXi kernel sloja. Rezultati sa hosta zatim se porede sa podacima storage sistema i mrežne ili SAN infrastrukture za isti vremenski interval.

Kada se datastore popunjava, cilj nije samo trenutno oslobađanje nekoliko gigabajta. Potrebno je utvrditi da li prostor troše snapshot-i, rast thin diskova, backup poslovi, ISO datoteke, klonovi ili nedovoljno planiran kapacitet. Posebno je važno da se VMDK i snapshot datoteke ne brišu ručno, jer takva intervencija može trajno prekinuti lanac virtuelnog diska.

Dobar VMware administrator tokom incidenta istovremeno štiti podatke, čuva dokaze, ograničava uticaj i radi od simptoma prema osnovnom uzroku. Tek kada su datastore, uređaj, sve očekivane putanje, performanse i virtuelne mašine ponovo stabilni, incident se može smatrati završenim.

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