L'esecuzione permanente in uno snapshot VMWare non è ottimale per le prestazioni?

Capisco che VMWare KB aggrotta le sopracciglia su istantanee di lunga durata principalmente a causa di due cose (secondo me)

Fare tonnellate di istantanee può riempire l'archivio dati. Le istantanee sono semplicemente file delta. Diciamo che hai un VMDK da 50 Gig, quasi pieno, e fai uno snapshot. Nella tua istantanea capovolgi ogni singolo bit. Il tuo file delta sarà anche di circa 50 GB. Snapshot di nuovo, capovolgi i bit, un altro file delta da 50 Gig. Questi possono perdere rapidamente il controllo.
Commettere grandi istantanee comporta rischi. Quando si consolidano le istantanee, si stanno scrivendo le modifiche delta nel VMDK originale. Ciò richiede tempo e comporta il rischio che, in caso di problemi, si verifichi il cloud VMDK.

I loro avvertimenti sembrano avere un senso logico.

Detto questo, è intrinsecamente male eseguire la mia macchina in modo permanente da un VMDK di snapshot? Voglio rendere il mio albero il seguente:

Base
- Snap1
  - Snap 2
  - Tu sei qui

Gli snap 1 e 2 verranno eseguiti immediatamente dopo l'installazione e il provisioning del sistema di base. Queste sono macchine che ho intenzione di aggiornare frequentemente, quindi farò semplicemente apparire il mio albero come segue:

Base
- Snap1
  - Tu sei qui
  - Snap 2

Elimina Snap2 e ricrea Snap2.

Non riesco a vedere come ciò possa avere implicazioni per i seguenti motivi:

Dal momento che ho semplicemente installato un'immagine di base e ho preso i miei delta subito dopo non è possibile riempire l'archivio dati. Supponendo che la mia immagine di base sia solo 10 GB (su un disco con thin provisioning da 50 GB), anche se il mio delta è invertito ogni singolo bit, il mio utilizzo totale massimo potrebbe essere di 60 GB (VMDK di base da 10 GB che è bloccato + 50 GB di delta in il file VMDK dello snapshot). Ciò presuppone che non crei ulteriori snapshot.
Dal momento che il mio caso d'uso non richiede il consolidamento delle istantanee, non rischio errori nel consolidamento dei miei delta. Quando torno a Snap1 e cancello Snap2, tutto il delta residente in Snap2 viene semplicemente eliminato.
Il carico di archiviazione è esattamente lo stesso, quindi dovrei ottenere gli stessi IOPS. Capisco che alcuni file (principalmente file di sistema) esisteranno sul VMDK originale e altri (tutto dopo la base) risiederanno nel delta, ma non vedo come ESXI se ne fregerebbe. Tutti i file si trovano sullo stesso archivio dati fisico, quindi le prestazioni dovrebbero essere equivalenti a fare riferimento a tutto nel VMDK originale senza snapshot.

qualche idea? ESXI 5.5 con l'archivio dati come RAID'd DAS.

Non ho una licenza vCenter, quindi la creazione di modelli e la clonazione è fuori dal tavolo.

RISULTATI DELLA PROVA

Sono arrivato presto oggi per eseguire alcuni test. Ecco i risultati C'è una penalità per le prestazioni ma non sono sicuro del perché.

Prima dell'istantanea:

Dopo l'istantanea: Dopo Shapshoting

— VM_Storage_Inception
fonte

Non sicuramente - col passare del tempo, le istantanee divergeranno sempre di più. Infine, saranno copie sostanzialmente diverse. Dopo non aver risparmiato molto disco eseguendone l'istantanea, converti l'istantanea in un volume completamente separato. Come? Normalmente, utilizzo dd da una terza macchina virtuale, ma per lo più sono quasi crocifisso qui per opinioni eretiche come questa. :-) Ma: funzionerà e sarà efficace .

— Peter - Ripristina Monica il

@PeterHorvath - Questa è la roba che amo sentire. Soluzioni intelligenti, confuse, efficaci, a ossa nude. Se non ti dispiace potresti darmi un commento su cosa fai in pastebin o qualcosa del genere? DD il VMDK e l'istantanea insieme?

— VM_Storage_Inception il

Se avessi bisogno di farlo più spesso, l'ho fatto con una sceneggiatura. Ma non è così, e nella maggior parte dei casi non uso nemmeno le istantanee, perché sono lente.

— Peter - Ripristina Monica il

Risposte:

Sì, ci sono implicazioni sulle prestazioni per le istantanee di lunga durata. Ci sono implicazioni ancora maggiori per il consolidamento dei VMDK delta nel file del disco originale. Ciò può causare non risposta nel sistema operativo della VM o altri comportamenti indesiderati.

VMware ha funzionalità di template e clonazione integrate in vCenter. Per abilitarlo è necessaria una licenza vSphere Essentials da $ 600.

Puoi creare una macchina virtuale secondo i tuoi gusti, quindi clonarla su un modello. Tale modello può quindi essere utilizzato per generare nuove macchine virtuali da un'immagine "Golden Master".

inserisci qui la descrizione dell'immagine

Ciò consente di avere uno "stato pulito", ma anche di creare VM permanenti o permanenti da quell'immagine principale. Non sono necessarie istantanee.

— ewwhite
fonte

Interessante, lo esaminerò e vedrò come funziona. Sfortunatamente non ho una licenza vCenter e preferirei che la mia organizzazione non sborsasse i $ 600 se non ci fossero implicazioni sulle prestazioni degli snapshot usati nel modo in cui descrivo. Anche il modello e la clonazione non sembrano diversi dal prendere un OVA e ridistribuirlo. L'eliminazione delle snapshot sembra molto più rapida e non riesco a vedere logicamente come potrebbero esserci conseguenze sulle prestazioni anche se non si tratta del "metodo ufficiale approvato da VMWare".

— VM_Storage_Inception il

Per rispondere alla tua modifica, potresti indicarmi un articolo o spiegare quali sarebbero le implicazioni sulle prestazioni? Non riesco a vedere come ci si potrebbe assumere supponendo che li uso come descrivo. Inoltre non avrei mai consolidato le istantanee al VMDK originale.

— VM_Storage_Inception il

Immagino che sto cercando di capire perché stai insistendo nel progettare una funzionalità che dovrebbe essere utilizzata per l'accesso a breve termine.

— ewwhite,

@VM_Storage_Inception - sembra quasi che tu voglia l'approccio di un povero al defunto Lab Manager del prodotto VMWare.

— TheCleaner

A volte, l' acquisto della soluzione giusta ha senso. Hai speso più impegno e ore lavorative a indagare su una soluzione alternativa rispetto al semplice pagamento di una licenza vSphere Essentials ($ 600), che ti darebbe un'opzione di clonazione / modello supportata.

— ewwhite,

La risposta di ewwhite è corretta, ma solo per espandere un po 'di più o la penalità prestazionale, considera il seguente scenario:

Si crea una macchina virtuale. Una lettura virtuale da vmdk accetta una lettura del disco fisico della stessa dimensione. Abbastanza semplice.

Ora immagina di scattare un'istantanea della VM. Ora, per ogni lettura virtuale, dovrai sostenere 2 letture fisiche, una dalla vmdk di base e una dalla vmdk delta, perché hai bisogno di informazioni da entrambi per ottenere lo stato corrente. Ora sei al doppio della lettura del disco fisico.

Per due istantanee, stai facendo tre volte le letture e così via. Se hai molte istantanee, puoi vedere come questa può essere una penalità di prestazione abbastanza significativa. Non si traduce necessariamente in prestazioni n-volte peggiori (a causa della memorizzazione nella cache, sezioni che non sono state modificate, ecc.), Ma non è una buona pratica.

— tfrederick74656
fonte

Sono quasi sicuro che le istantanee utilizzino una tabella "quale blocco si trova in quale file". Quindi la lettura di un singolo blocco si tradurrà in un solo blocco letto dal file appropriato. Naturalmente, la lettura di più blocchi può comportare l'accesso a più file, il che significa una penalità per lo spostamento delle testine del disco se non si esegue da un SSD, ma il numero totale di accessi ai blocchi del disco non dovrebbe cambiare.

— Guntram Blohm supporta Monica il

Per come lo capisco, le istantanee memorizzano solo le modifiche dal disco originale. Se si memorizza il file A, quindi si crea un'istantanea, quindi si cambia di nuovo il file A, solo le modifiche a quel file vengono scritte nell'istantanea. Pertanto, è necessario leggere sia il VMDK originale sia l'istantanea per ottenere l'intero file. Altrimenti, ogni istantanea sarebbe semplicemente una copia completa del disco originale, che non lo sono.

— tfrederick74656,

potrebbe essere corretto, ma la quantità totale di blocchi che è necessario leggere rimane invariata (ad es. 10 blocchi dall'istantanea e 100 dal disco di base). ESXi controlla innanzitutto le istantanee esistenti per i blocchi necessari fino a quando non si esaurisce nell'istantanea corretta (o sul disco di base). Potrebbe esserci una penalità minore perché il sistema probabilmente salterà completamente quella parte che attraversa l'istantanea quando non è presente alcuna istantanea. Inoltre, un file di snapshot di lunga durata probabilmente soffrirà di una forte frammentazione.

— Dirk Trilsbeek,

Un sistema di snapshot del disco virtuale che esegue N legge per N snapshot sarebbe un'implementazione molto stupida. Dubito che sia così implementato in VMWare. Una semplice ottimizzazione potrebbe essere fatta semplicemente creando un file indice che memorizza in quale file del disco si trova ciascun blocco dell'unità emulata. Supponiamo di avere un disco virtuale da 512 GB con una dimensione del blocco di 4 KB, è necessario solo un indice da 64 MB per determinare in tempo costante quale file di disco virtuale fino a 16 contiene un blocco.

— Lie Ryan,

Sulla base delle risposte in serverfault.com/questions/430138 non sono d'accordo. Ho sempre pensato alle istantanee come il risultato dell'aritmetica binaria, non solo una raccolta di nuovi dati. Quindi se hai i bit 01010101 nel tuo VMDK di base, fai un'istantanea, quindi cambi quei bit in 10101010, il tuo delta conterrebbe 11111111 (indicando che ogni bit nel file originale è cambiato, NON il nuovo valore di 10101010). Per quanto sia d'accordo con il commento sopra, i VMDK sono file apparentemente grezzi. Dove sarebbe memorizzato l'indice? Non l'ho mai visto menzionato in nessun pub tecnologico VMWare.

— tfrederick74656,

Le istantanee di VMware ESX sono pensate per un uso a breve termine.

Un utilizzo prolungato e un IO elevato possono causare blocchi della VM. Se si verifica un caso in cui IO di scrittura è più grande / più veloce del consolidamento dell'istantanea, ESX bloccherà la VM per proteggere i dati. Con le snapshot temporali frammentate e ESX esegue il consolidamento interno, è possibile che si verifichino blocchi periodici.

È possibile eseguire il modello di VM manualmente tramite ssh. Copia la cartella VM contenente vmdk, vmx, ecc. In una nuova cartella. Nel file vmx della VM appena copiata cambia UID e indirizzo MAC.

VMware ha un prodotto, Linked Clone, che è la stessa cosa che stai cercando di fare. E dicono che ha potenziali problemi di prestazioni. In pratica, dopo un po 'rimasterizzerai le macchine virtuali. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— dario
fonte