Questo post è disponibile anche in: Inglese

Reading Time: 4 minutes

Se state usando Veeam Backup & Replication con un datastore VMware vSAN, probabilmente avrete dato un’occhiata alla Veeam KB 2273 (Configuration for VMware VSAN) per capire quale fosse la configurazione e la modalità ottimale. Ma la KB si limita a raccomandare la modalità di trasporto hot-add.

Quindi avrete creato diversi proxy Veeam sotto forma di diverse VM nell’ambiente vSAN… magari persino 1 VM per ogni host (come qualcuno consiglia).

Ma quando lanciate i job di backup vi accorgete le prestazioni non sono così eccelse… O meglio lo possono essere per il backup full… ma sull’incrementale le prestazioni possono essere lente e in alcuni casi con tempi simili a quello del backup full.

Guardando i dettagli del job di backup in esecuzione, vi accorgere che molte VM sono in coda, in atteasa di qualche cosa: o di un proxy, o di un repository, o persino del datastore vSAN.

In quest’ultimo caso, il messaggio che vedrete è il seguente:

Resouce not ready: Active snapshosts limit reached for datastore

Che cosa significa?

Veeam ha definito arbitrarimente un numero massimo di “active VM snapshots per datastore” per limitare e minimizzare eventuali problemi causati dalle snapshot di VMware… ad esempio legate alla loro cancellazione o l’impatto che possono avere sulle prestazioni di un datastore… o semplicemente al fatto che più ce ne sono e più i file delta crescono e meno spazio disponibile rimane nel datastore.

Però nel caso di VSAN TUTTE le VM sono in unico datastore e questo limite (di default 4 active snapshots) è eccessivo e vi rallenterà i backup incrementali, dove molto tempo già si perde tra cercare la VM, prepararla per l’hot-add, … piuttosto che per fare il backup vero e proprio.

Inoltre su vSAN le snapshot sono leggermente diverse e meno “problematiche” delle normali snapshot (questo grazie al particolare filesystem usato da vSAN).

Quindi può convenire cambiare questo parametro, ma è possibile sono dal registro di Windows, come documentato da questo community post.

La chiave di registro è MaxSnapshotsPerDatastore (REG_DWORD) e si trova in:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

Notare che si tratta di un chiave di tipo DWORD (32 bit) che può essere impostata con valori esadecimali o decimali, ovviamente il risultato sarebbe diverso:

  • Se scrivete 12 in decimale, il valore memorizzato sarà DWORD 0x0000000c
  • Se scrivete 12 in esadecimale il valore memorizzato sarà DWORD 0x00000012 che corrisponde a 18 decimale

Dopo aver modificato il registro (solo sul Veeam Backup) è necessario riavviare il servizio di Veeam Backup stesso (non serve riavvare tutti i servizi).

Aumentare questo valore vuol dire ridurre il tempo di attesa dentro i job di backup, soprattutto quando avete tante VM e quanto il backup è incrementale.

Ma qual è il valore ottimale? Bisogna fare alcune prove visto che poi ci possono essere altri limiti sui proxy o sui repository e quindi dipende da ambiente ad ambiente. Nel mio caso ho trovato un buon compromesso tra 8 e 12 grazie al quale sono riuscito a dimezzare (quasi) il tempo dei backup job incrementali.

Notare invece che per quanto riguarda le storage snapshots (solo per ambienti VMware vSphere) il ragionamento è simile, ma ci sono altre opzioni e limiti. In questo gestibili dall’interfaccia grafica.

E’ possibile usare il valore Limit processed VM count per storage snapshot:

Purtroppo VMware vSAN non ha un’integrazione di questo tipo e quindi l’unica via è lavorare con la chiave di registro.

Andrea MauroAbout Andrea Mauro (2855 Posts)

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


Share