A execução permanente em um instantâneo do VMWare é ruim para o desempenho?

Entendo que o VMWare KB desaprova snapshots de execução longa, principalmente devido a duas coisas (na minha opinião)

Tirar toneladas de instantâneos pode preencher o armazenamento de dados. Instantâneos são simplesmente arquivos delta. Digamos que você tenha um VMDK de 50 Gig, quase cheio, e tire uma foto instantânea. No seu instantâneo, você vira cada bit. Seu arquivo delta também terá cerca de 50 GB. Instantâneo novamente, vire os bits, outro arquivo delta de 50 Gig. Estes podem sair do controle rapidamente.
Confirmar snapshots grandes traz riscos. Ao consolidar snapshots, você está gravando as alterações delta no VMDK original. Isso leva tempo e corre o risco de que, se algo acontecer, você apenas desmontou o seu VMDK.

Seus avisos parecem fazer sentido lógico.

Com isso dito, é inerentemente ruim executar minha máquina permanentemente fora de um instantâneo VMDK? Quero fazer da minha árvore o seguinte:

Base
- Snap1
  - Snap 2
  - Você está aqui

Os snap 1 e 2 serão tirados imediatamente após a instalação e o provisionamento do sistema base. Estas são máquinas que pretendo atualizar com frequência, para que minha árvore fique com a seguinte aparência:

Base
- Snap1
  - Você está aqui
  - Snap 2

Exclua o Snap2 e recrie o Snap2.

Não vejo como isso pode ter implicações pelos seguintes motivos:

Como eu simplesmente instalei uma imagem de base e peguei meus deltas imediatamente depois, de maneira alguma poderia encher o repositório de dados. Supondo que minha imagem base tenha apenas 10 GB (em um disco provisionado thin de 50 GB), mesmo que meu delta tenha invertido cada bit, o máximo que meu uso total poderia ter é de 60 GB (VMDK base de 10 GB bloqueado + 50 GB de delta em o arquivo VMDK da captura instantânea). Isso pressupõe que eu não crio nenhum instantâneo adicional.
Como meu caso de uso não exige a consolidação dos instantâneos, não arrisco erros ao consolidar meus deltas. Quando volto ao Snap1 e excluo o Snap2, todo o delta que residia no Snap2 simplesmente é excluído.
A carga de armazenamento é exatamente a mesma, então eu deveria estar recebendo o mesmo IOPS. Entendo que alguns arquivos (principalmente arquivos do sistema) existirão no VMDK original e outros (tudo depois da base) residirão no delta, mas não vejo como o ESXI se importaria. Todos os arquivos estão no mesmo armazenamento de dados físico, portanto, o desempenho deve ser equivalente a fazer referência a tudo no VMDK original sem capturas instantâneas.

Alguma ideia? ESXI 5.5 com o armazenamento de dados sendo DAS RAID.

Como não tenho uma licença do vCenter, a modelagem e a clonagem estão fora de questão.

RESULTADOS DO ENSAIO

Cheguei cedo hoje para fazer alguns testes. Aqui estão os resultados. Há uma penalidade de desempenho, mas não sei por que.

Antes da captura instantânea:

Após o instantâneo: Após Shapshoting

— VM_Storage_Inception
fonte

Não é certo - com o tempo, os instantâneos divergem cada vez mais. Finalmente, serão essencialmente cópias diferentes. Depois de não poupar muito disco capturando-os instantaneamente, converta-os em um volume completamente separado. Quão? Normalmente, eu uso o dd de uma terceira VM, mas quase sempre sou crucificado aqui por opiniões heréticas, como esta. :-) Mas: funcionará e será eficaz .

— peterh diz restabelecer Monica

@ PeterHorvath - É o que eu mais gosto de ouvir. Soluções inteligentes, hacky, eficazes e básicas. Se você não se importa, poderia me escrever sobre o que faz em pastebin ou algo assim? Você DD o VMDK e captura instantânea juntos?

— VM_Storage_Inception

Se eu precisava fazer isso com mais frequência, fazia-o com um script. Mas não é esse o caso e, na maioria dos casos, eu não uso nem mesmo snapshots, pois eles são lentos.

— peterh diz restabelecer Monica

Respostas:

Sim, há implicações de desempenho para instantâneos de execução longa. Existem implicações ainda maiores para consolidar os VMDKs delta de volta ao arquivo de disco original. Isso pode causar falta de resposta no sistema operacional da sua VM ou outro comportamento indesejável.

O VMware possui funcionalidade de modelagem e clonagem incorporada ao vCenter. Você precisa de uma licença do vSphere Essentials de US $ 600 para ativar isso.

Você pode criar uma VM ao seu gosto e cloná-la em um modelo. Esse modelo pode ser usado para gerar novas máquinas virtuais a partir de uma imagem "Golden Master".

insira a descrição da imagem aqui

Isso permite que você tenha um "estado limpo", mas também crie VMs permanentes ou de execução longa a partir dessa imagem principal. Não são necessários instantâneos.

— ewwhite
fonte

Interessante, vou analisar isso e ver como isso funciona. Infelizmente, eu não tenho uma licença do vCenter e prefiro que minha organização não pague os US $ 600 se não houver implicações de desempenho para os instantâneos que estão sendo usados da maneira que descrevo. Além disso, a modelagem e a clonagem não parecem diferentes do que pegar um OVA e reimplantá-lo. A exclusão dos snapshots parece muito mais rápida e não consigo ver logicamente como haveria implicações no desempenho, mesmo que não seja o "método oficial aprovado pelo VMWare".

— VM_Storage_Inception

Para responder à sua edição, você poderia me indicar um artigo ou explicar quais seriam as implicações no desempenho? Não vejo como supor que eu os use como descrevo. Além disso, eu nunca consolidaria os instantâneos de volta ao VMDK original.

— VM_Storage_Inception

Acho que estou tentando entender por que você está insistindo em criar um recurso que deve ser usado para acesso a curto prazo.

— precisa saber é o seguinte

@VM_Storage_Inception - quase parece que você está querendo uma abordagem de pobre para o extinto produto Lab Manager da VMWare.

— TheCleaner

Às vezes, comprar a solução certa faz sentido. Você gastou mais esforço e horas de trabalho perguntando sobre uma solução alternativa do que apenas pagar por uma licença do vSphere Essentials (US $ 600), o que forneceria uma opção de modelo / clonagem suportada.

— precisa saber é o seguinte

A resposta do ewwhite está correta, mas apenas para expandir um pouco mais ou a penalidade de desempenho, considere o seguinte cenário:

Você cria uma VM. Uma leitura virtual do vmdk recebe uma leitura de disco físico do mesmo tamanho. Bastante direto.

Agora imagine que você tira um instantâneo da VM. Agora, para cada leitura virtual, você terá duas leituras físicas, uma da base vmdk e outra da delta vmdk, porque você precisa de informações de ambas para obter o estado atual. Agora você está duas vezes mais que o disco físico lê.

Para dois instantâneos, você faz três vezes as leituras e assim por diante. Se você tiver muitos instantâneos, poderá ver como isso pode ser uma penalidade de desempenho bastante significativa. Ele não se traduz necessariamente em um desempenho n-vezes pior (devido ao cache, seções que não foram alteradas etc.), mas não é uma boa prática.

— tfrederick74656
fonte

Tenho quase certeza de que os instantâneos usam uma tabela "que bloco está em qual arquivo". Portanto, a leitura de um único bloco resultará apenas na leitura de um bloco no arquivo apropriado. Obviamente, a leitura de vários blocos pode resultar no acesso a vários arquivos, o que significa uma penalidade por mover cabeças de disco se você não estiver executando a partir de um SSD, mas o número total de acessos a blocos de disco não deve mudar.

— Guntram Blohm apoia Monica

Pelo que entendi, os instantâneos armazenam apenas alterações do disco original. Se você armazenar o arquivo A, tire um instantâneo e altere o arquivo A novamente, apenas as alterações nesse arquivo serão gravadas no instantâneo. Portanto, você precisa ler o VMDK original e o instantâneo para obter o arquivo inteiro. Caso contrário, cada instantâneo seria simplesmente uma cópia completa do disco original, o que não é.

— precisa saber é o seguinte

isso pode estar correto, mas a quantidade total de blocos que você precisa ler permanece a mesma (por exemplo, 10 blocos do snapshot e 100 do disco base). O ESXi verifica primeiro os snapshots existentes quanto aos blocos necessários até terminar no snapshot correto (ou no disco base). Pode haver uma penalidade menor, porque o sistema provavelmente ignorará completamente a parte transversal do instantâneo quando não houver nenhum instantâneo. Além disso, um arquivo de instantâneo de longa execução provavelmente sofrerá uma fragmentação grave.

— Dirk Trilsbeek

Um sistema de instantâneo de disco virtual que lê N para instantâneo de N seria uma implementação muito estúpida. Duvido que seja implementado no VMWare. Uma otimização simples pode ser feita simplesmente criando um arquivo de índice que armazena em qual arquivo de disco cada bloco da unidade emulada está. Suponha que você tenha um disco virtual de 512 GB com tamanho de bloco de 4kB, você só precisa de um índice de 64 MB para determinar em tempo constante qual dos 16 arquivos de disco virtual contém um bloco.

— Lie Ryan

Com base nas respostas em serverfault.com/questions/430138, tenho que discordar. Eu sempre pensei em snapshots como resultado da aritmética binária, não apenas uma coleção de novos dados. Portanto, se você tiver os bits 01010101 no VMDK base, faça uma captura instantânea e altere esses bits para 10101010, seu delta conterá 11111111 (indicando que todos os bits no arquivo original foram alterados, NÃO o novo valor de 10101010). Por mais que eu concorde com o comentário acima, os VMDKs são arquivos supostamente brutos. Onde o índice seria armazenado? Nunca vi isso mencionado em nenhum dos pubs de tecnologia VMWare.

— precisa saber é o seguinte

Os instantâneos do VMware ESX destinam-se ao uso a curto prazo.

O uso prolongado e o IO pesado podem causar congelamentos da VM. Se você tiver casos em que a E / S de gravação for maior / mais rápida que a consolidação de instantâneos, o ESX congelará a VM para proteger os dados. Com o tempo, os snapshots são fragmentados e o ESX faz a consolidação interna. Você pode experimentar congelamentos periódicos.

Você pode executar o modelo da VM manualmente através do ssh. Copie a pasta VM contendo vmdk, vmx, etc. para uma nova pasta. No arquivo vmx da VM recém-copiada, altere o endereço UID e MAC.

A VMware possui o produto, Clone vinculado, que é a mesma coisa que você está tentando fazer. E eles dizem que tem potenciais problemas de desempenho. Na prática, você remasterizará as VMs depois de um tempo. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— dario
fonte