Quali sono le conseguenze sulle prestazioni dell'esecuzione di macchine virtuali su un host ZFS?

Sto pensando di migrare da ext3 a ZFS per l'archiviazione dei dati sul mio host Debian Linux, usando ZFS su Linux . Una caratteristica killer di ZFS che voglio davvero è la sua garanzia di integrità dei dati. La capacità di aumentare banalmente lo spazio di archiviazione man mano che il mio spazio di archiviazione deve aumentare è anche qualcosa che non vedo l'ora.

Tuttavia, eseguo anche alcune macchine virtuali sullo stesso host. (Anche se normalmente, nel mio caso, sull'host è in esecuzione una sola VM alla volta.)

Considerando il checksum dei dati di ZFS e il comportamento del copy-on-write, insieme al fatto che le immagini del disco della VM sono file relativamente grandi (il file di immagine del disco della mia VM principale si trova attualmente a 31 GB), quali sono le implicazioni delle prestazioni all'interno del guest VM di tale una migrazione? Quali passi posso prendere per ridurre il possibile impatto negativo sulle prestazioni?

Posso vivere con meno garanzie di integrità dei dati sulle immagini del disco della VM, se necessario (non faccio nulla di veramente critico all'interno di nessuna delle VM) e posso separarle facilmente dal resto del filesystem, ma sarebbe bello se non lo facessi Devo (anche selettivamente) disattivare praticamente la funzione che più mi fa venire voglia di migrare su un file system diverso.

L'hardware è piuttosto robusto per un sistema di classe workstation, ma non reggerebbe molto a un server di fascia alta (32 GB di RAM con raramente> 10 GB in uso, CPU a 6 core da 3,3 GHz, attualmente 2,6 TB utilizzabili spazio su disco in base a dfun totale di circa 1,1 TB libero; la migrazione a ZFS aggiungerà probabilmente più spazio libero ) e non sto pianificando di eseguire la deduplicazione dei dati (poiché l'attivazione del dedup non aggiungerebbe molto nella mia situazione). Il piano è di iniziare con una configurazione JBOD (ovviamente con buoni backup) ma alla fine potrei passare a una configurazione mirror a due vie se le condizioni lo giustificano.

Poiché ZFS funziona a livello di blocco, la dimensione dei file non fa alcuna differenza. ZFS richiede più memoria e CPU ma non è intrinsecamente significativamente più lento come file system. Sebbene sia necessario essere consapevoli del fatto che RAIDZ non è equivalente in termini di velocità a RAID5. RAID10 va bene dove la velocità è una priorità.

ZFS su hardware decente (ad es. Buff) sarà probabilmente più veloce di altri file system, probabilmente vorrai creare uno ZIL su una posizione veloce (ad es. SSD). Questo è essenzialmente un percorso per scrivere nella cache (beh, più come un diario in ext3 / 4). Ciò consente alla casella ack di scrivere come scritta sul disco prima che i mandrini effettivi abbiano i dati.

È inoltre possibile creare un ARC L2 su SSD per la cache di lettura. Questo è fantastico in un ambiente VM in cui è possibile mettere in ginocchio i dischi fisici avviando più VM contemporaneamente.

Le unità vanno in VDEV, i VDEV in zpools (si prega di utilizzare interi dischi alla volta). Se questo è un sistema più piccolo, potresti voler avere un singolo zpool e (se non sei troppo preoccupato per la perdita di dati) un singolo VDEV. I VDEV sono i punti in cui si seleziona il livello RAID (sebbene sia possibile anche i VDEV a SPECCHIO se si hanno abbastanza dischi). Il disco più lento in un VDEV determina la velocità dell'intero VDEV.

ZFS si basa sull'integrità dei dati - il motivo per cui non esistono molti strumenti tradizionali per la manutenzione del file system (come fsck) è il problema che risolvono non può esistere su un file system ZFS.

IMO il più grande svantaggio di ZFS è che se i tuoi file system si avvicinano completamente (diciamo 75% +) diventa MOLTO lento. Basta non andarci.

31 GB in realtà non è affatto grande ...

Ad ogni modo, a seconda del file system attualmente in uso, è possibile che ZFS sia leggermente più lento, ma date le specifiche hardware potrebbe essere trascurabile.

Ovviamente ZFS utilizzerà una buona porzione di RAM per la memorizzazione nella cache che può far sembrare le macchine virtuali più "scattanti" in uso generale (quando non si eseguono pesanti operazioni di lettura o scrittura). Non sono sicuro di come ZFS sia ottimizzato su Linux ma potrebbe essere necessario limitare il suo ARC, se possibile, per impedirlo di scappare via con tutta la RAM (visto che vorrai un pezzo decente lasciato sul tuo sistema host e VM).

Vorrei abilitare la compressione (il consiglio in questi giorni è di attivarlo a meno che tu non abbia una buona ragione per non farlo). Ricorda che questo deve essere fatto prima di inserire i dati nel file system. La maggior parte delle persone è sorpresa di scoprire che in realtà è più veloce, dato che gli algoritmi di compressione funzioneranno generalmente più velocemente dell'IO del disco. Dubito che causerà un grosso problema di prestazioni con il tuo processore a 6 core. Non mi aspettavo che le macchine virtuali comprimessero molto, ma sono riuscita a trasformare ~ 470 GB di dati di macchine virtuali in 304 GB solo con l'impostazione di compressione predefinita.

Non preoccuparti della dedupe, tornerà a perseguitarti più tardi e passerai settimane a mescolare i dati cercando di sbarazzartene.

Se riscontri problemi di prestazioni, la risposta ovvia è aggiungere un SSD come ZIL / L2ARC o anche entrambi. Non è l'ideale per utilizzare un dispositivo per entrambi, ma molto probabilmente migliorerà comunque le prestazioni su un pool contenente un piccolo numero di dischi / vdev.

Per aggiungere: proverei davvero a iniziare con una configurazione ridondante, se possibile (idealmente mirror), o convertire in mirror da una striscia il più presto possibile. Mentre ZFS eseguirà il checksum di tutti i dati e rileverà gli errori al volo (o durante uno scrub), non sarà in grado di fare nulla al riguardo (senza utilizzare copie = 2 che raddoppierà l'utilizzo del disco). Ti resterà solo che ti dice che ci sono errori nei file (probabilmente le immagini del tuo disco VM) di cui non sarai in grado di fare molto senza eliminare e ricreare quei file.

A seconda dei casi d'uso e delle macchine virtuali, prenderei in considerazione quanto segue. Lascia che il sistema operativo host si occupi dei file che stai memorizzando sui volumi ZFS.

Se possibile, creare solo un LUN per ogni VM, contenente solo il sistema operativo e i file binari necessari. E presentare lo spazio di archiviazione per i dati individuali come condivisioni tramite NFS, samba o iSCSI (o zvols come menzionato nei commenti). ZFS è in grado di tenere traccia di ogni file con checksum e tempi di accesso ect. Naturalmente, se la velocità non è così importante, è possibile abilitare anche la compressione su alcuni archivi dati. Il vantaggio sarebbe uno strato mancante di un altro filesystem. Se dovessi creare un LUN per il secondo disco rigido virtuale e creare un filesystem NTFS al di sopra di questo, ZFS deve gestire un grande BLOB binario e non conosce alcun contenuto o file e quindi non può sfruttare la cache ZIL o ARC in allo stesso modo dei file aerei.

Menzionando gli ACL, ZFS è in grado di usare gli ACL tramite NFSv4 o Samba (se abilitato). Devo ammettere che uso ZFS su FreeBSD e non posso assicurare come abilitare gli accoppiamenti ACL Sambas su volumi ZFS. Ma sono sicuro che questo non dovrebbe essere un grosso problema.

La deduplicazione in combinazione con una cache di lettura è un grande vantaggio quando si tratta di risparmiare spazio e migliorare letture di massa (Boot storm) poiché tutte le macchine virtuali iniziano a leggere gli stessi blocchi.

Lo stesso vale per le istantanee ZFS per le macchine virtuali e i datastore. È possibile creare un semplice script shell, congelare la VM, scattare un'istantanea della VM e del Datastore e continuare a lavorare, o solo il Datastore da solo, e clonare la VM per presentare l'istantanea di quella originale e testare alcune cose.

Le possibilità sono infinite con ZFS;)

EDIT: Spero di averlo spiegato un po 'meglio ora

EDIT2: opinione personale: considerare l'utilizzo di un RAIDZ2 (RAID6) in quanto è possibile resistere a un errore del doppio disco! Se è rimasto un solo disco di riserva, non sarà mai sbagliato, ma due guasti del disco dovrebbero essere sufficienti per una rapida risposta. Ho appena postato il mio script per monitorare lo stato del disco qui