This post is also available in: Inglese

Reading Time: 3 minutes

Durante l’aggiornamento a vSphere 5, nel momento di scegliere il tipo di VMFS dei datastore, vi è un potenziale dubbio decisionale: è meglio procedere con l’aggiornamento dei datastore VMFS3 esistenti o è meglio create nuovi datastore direttamente con VMFS5? Dato che l’aggiornamento è veloce ed indolore e, soprattutto, che può essere eseguito a caldo, si potrebbe pensare che l’aggiornamento sia la strada migliore.

In realtà vi sono alcune ragioni per le quali può essere meglio procedere con nuovi datastore:

  • Block size: VMFS5 utilizza un unified block size da 1 MB. In caso di upgrade il block size rimane quello originale del VMFS3 di partenza. E’ anche vero che non vi sono differenze di prestazioni rilevanti tra i vari block size.
  • GPT table: in caso di upgrade il datastore VMFS5 rimane con il vecchio formato MBR… In realtà poi basta farlo crescere sopra i 2 TB (limite del formato MBR) per far sì che venga convertito in GTP.
  • LUN size: prima di vSphere 4 le dimensioni delle LUN erano di solito contenute (in particolare per i possibili problemi di locking). Ma troppe LUN porta a molta frammentazione, quindi questo potrebbe essere il momento giusto per riorganizzare tutti i datastore in meno LUN più grandi.
  • Partition alignment: benché i datastore VMFS3 fossero già allineati (a parte quello creato durante l’installazione di ESX o ESXi) la partizione inizia dal settore 128; nei nuovi VMFS5 le partizioni iniziano dal settore 2,048.
  • Internal filesystem structure: un VMFS5 ottenuto da un upgrade continuerà ad usare i sub-blocks da 64KB (e non i nuovi da 8K) e avrà il limite dei file a 30,720 (anziché il nuovo limite  > 100,000).
  • Check zoning: questo può essere un buon momento per ricontrollare lo zoning, il masking e le regole di accesso alle LUN. Nel caso di iSCSI si potrebbero trovare target non più usati.

Quindi, al di là di piccole differenze nella struttura di un nuovo VMFS5 rispetto ad uno aggiornato, partire da zero ha il vantaggio di permette di rivedere la struttura e fare pulizia della stessa. Ovviamente richiede abbastanza spazio per creare nuovi datastore e tempo per migrare le VM. Con Storage vMotion non sono previsti downtime, ma ovviamente questo richiede licenze di tipo Enterprise o Enterprise+. Spostare le VM ha inoltre il vantaggio di rinominarle (in modo che i nomi corrispondano all’inventario), ripulirle da snapshot (vanno consolidati prima della migrazione), da file temporanei, … lasciando tra l’altro in evendenza se vi sono VM non in inventario, file creati manualmente, ISO che magari non servono più, …

PErò esiste almeno una buona ragione per tenere un datastore aggiornato e non creato da zero: se utilizzare vmdk thin e volete periodicamente “compattarli” con un reclaim del blocchi non usati, vi può tornare comodo un datastore con un block size diverso, come discusso nel precedete post.

Per maggiori informazioni sulle differenze tra VMFS3 e VMFS5 vedere anche (in inglese):

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.