Lagring är mer än ledigt utrymme
Lagring är en av de delar i VMware ESXi som tydligast påverkar användarupplevelsen. En VM kan ha rätt mängd CPU och minne men ändå kännas långsam om datastoren har hög latens eller om backupjobb belastar samma diskar vid fel tidpunkt. Därför bör lagringsdesign inte reduceras till frågan om hur många terabyte som finns lediga. Administratören behöver förstå protokoll, filsystem, köer, snapshots och hur flera värdar får åtkomst till samma data.
VMFS är VMwares eget filsystem för virtuella maskiner och används ofta på blocklagring via lokala diskar, SAN, Fibre Channel eller iSCSI. Det är byggt för att flera ESXi-värdar ska kunna komma åt samma datastore på ett kontrollerat sätt. NFS är ett annat vanligt alternativ där lagringen presenteras som en nätverksresurs. Båda modellerna kan fungera väl, men de kräver olika felsökningsmetoder. Vid VMFS tittar man ofta på pathing, HBA, ködjup och blocklagringens latens. Vid NFS behöver man även granska nätverk, MTU, exportinställningar och NAS-systemets beteende.
iSCSI, Fibre Channel och NFS
iSCSI är populärt eftersom det använder IP-nätverk och kan byggas med standardutrustning. Samtidigt ställer det krav på separering från vanlig VM-trafik, rätt multipathing och stabila switchar. Fibre Channel är ofta mycket förutsägbart i större datacenter, men kräver särskild infrastruktur och kompetens. NFS kan vara enkelt att administrera och fungerar bra i många miljöer, men nätverksdesignen måste vara konsekvent. Det finns inget universellt bäst val; rätt lösning beror på budget, kompetens, befintlig infrastruktur och krav på återställning.
För nya värdar bör lagringsvalet göras tillsammans med versions- och hårdvaruplanering. Om organisationen utvärderar VMware ESXi 8 bör den samtidigt kontrollera stöd för lagringskontroller, drivrutiner och backupintegrationer. En uppgradering är inte komplett förrän hela kedjan från hypervisor till lagringssystem och backup är verifierad.
Datastores och kapacitet
En datastore bör ha tydligt syfte. Blanda inte okritiskt alla arbetslaster på samma yta bara för att det finns plats. Databaser, filservrar, testmaskiner och backup-proxies har olika I/O-mönster. Om allt hamnar på samma datastore blir felsökning svårare och en intensiv arbetslast kan påverka många andra system. Namngivning hjälper: ett datastore-namn bör säga något om lagringstyp, plats, prestandanivå eller kluster.
Kapacitetsplanering handlar också om marginaler. Tunna diskar kan spara utrymme, men kräver övervakning så att datastoren inte fylls oväntat. Snapshots kan växa snabbt och bör bevakas noga. En full datastore kan stoppa virtuella maskiner eller göra snapshots omöjliga att konsolidera. Därför bör larm för ledigt utrymme, snapshotstorlek och latens vara aktiva från början.
Snapshots och backup
Snapshots är ett verktyg för kortvariga ändringar, inte en backupstrategi. De gör det möjligt att återgå efter en uppdatering eller konfigurationsändring, men de skapar differensfiler som växer när VM:en fortsätter skriva data. Om snapshots ligger kvar under lång tid kan de påverka prestanda och göra konsolidering riskfylld. Backupverktyg använder ofta snapshots tillfälligt, men de ska stängas och konsolideras korrekt efter jobbet.
Backup bör testas separat från snapshots. En återställningsplan är inte trovärdig förrän den har provats. Kontrollera att backupverktyget stödjer aktuell ESXi- och vCenter-version, att applikationskonsistens hanteras för databaser och att återläsning kan göras till annan värd eller annan datastore vid ett större fel. Lagringsdesign och backupdesign hör ihop; den ena kan inte bedömas utan den andra.
Felsökning av latens
När användare rapporterar långsamhet bör administratören skilja på latens i gästoperativsystemet, ESXi och lagringssystemet. Kontrollera datastore latency, device latency och kernel latency. Om flera VM:ar på samma datastore påverkas samtidigt pekar det ofta mot lagring eller nät. Om bara en VM påverkas kan orsaken vara applikationen eller dess virtuella disk. Metodisk felsökning gör att rätt team involveras snabbare och att man undviker onödiga ändringar i en fungerande miljö.