Como evitar que o VMware atinja um cliente durante a geração de imagens com a Veeam

Question

Recentemente nosso servidor MySQL foi "indo embora" (ou seja, a conexão do cliente cai). Depois de semanas tentando coisas diferentes (como ajustar o tamanho do pacote), descobrimos que são os backups de imagem da Veeam que usam a API do VMWare para capturar e copiar os vmdks, etc.

Estamos usando o ESXi 5 com um convidado do Centos 6.4, rodando (praticamente) somente o MySQL 5.1.69-log.

A mudança que parecia iniciar este problema foi aumentar o tamanho do disco físico para 300 GB, de cerca de 100, e redimensionar o sistema de arquivos convidado para usar a maior parte da nova capacidade. Desde que o disco foi aumentado, estamos obtendo esses problemas durante os backups - presumivelmente devido ao aumento de tempo necessário para executar funções relacionadas a snapshots.

Os novos discos são 2x300GB Gen8 15k SAS no RAID1. Os discos antigos teriam sido semelhantes apenas menores. O alvo do processo Veeam é um ReadyNAS sobre uma ethernet dedicada de 1Gb (ou seja, separado do tráfego geral do escritório).

O host é uma torre HP DL380P:

==server spec (BASE CHASSIS)==
SERIES DL380P GEN8
PROCESSOR TYPE Intel Xeon E5-2609 v2 (2.5GHz/4-core/10MB/6.4GT-s QPI/80W)
NUMBER OF PROCESSORS 2 
MEMORY 80GB
INTERNAL DRIVE BAYS 8 SFF HDD Bays
COMPATIBLE HDD SFF SAS/SATA
HARD DISK CONTROLLER SMART ARRAY P420I/ZERO MEMORY CONTROLLER (RAID 0/1/1+0)

Meu "cara de TI" fez alguns ajustes na configuração do Veeam, incluindo pular blocos vazios (a maioria do novo disco está vazio), mas isso não pareceu ajudar em nada.

Veeam também não ajudou muito, dizendo "reinicie o alvo" ou "nós apenas usamos APIs do VMWare".

Eu acredito que o "stun" significa que a máquina virtual simplesmente congela por um tempo (por volta de 30s) e continua normalmente.

exemplo VMWare.log:

Line 7411: 2016-06-08T17:11:44.910Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 21068381 us
Line 7556: 2016-06-08T17:22:24.608Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 19819322 us
Line 7700: 2016-06-08T17:22:30.140Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1130044 us
Line 7929: 2016-06-08T17:23:08.616Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 30197618 us

Então, meu problema tem duas soluções prováveis:

1. Existe uma maneira de evitar ou reduzir o "atordoamento" de um convidado do VMWare durante a geração de imagens.

2. Existe uma maneira de reduzir o impacto do stun no MySQL ou na rede virtual ou no Centos.

Answer 1

Este é um servidor HP ProLiant sendo executado com um controlador Smart Array RAID sem um módulo de cache com suporte a Flash.

Como resultado, você não tem cache de gravação ( ou cache de leitura ) e operações como instantâneos de máquinas virtuais sofrerão. Você já experimentou o efeito disso. A configuração atual é inadequada para a maioria das cargas de trabalho, especialmente a virtualização.

Sua melhor opção é simplesmente comprar um módulo de cache e bateria / FBWC; Peças HP 631681-B21, 631679-B21 ou 631069-B21.

Isso acelerará o desempenho e eliminará o problema que você está vendo.

Veja também:

FBWC e memória zero ( ZM) Controlador RAID no HP DL360p

BBWC: em teoria, uma boa ideia, mas uma vez salvou seus dados?

Qual é o módulo de memória em uma placa RAID necessária para?

    

Answer 2

Respondendo minha própria pergunta da pesquisa. (Eu só aceitarei minha própria resposta se uma dessas abordagens realmente funcionar e for antes da sugestão de outra pessoa.)

Este artigo (mais antigo) O QUE OS PERIGOS DOS INSTANTÂNEOS E COMO EVITAR? menciona algumas causas possíveis e três medidas preventivas. Curiosamente, ele menciona como o problema afeta de maneira semelhante o MS SQL Server e outros produtos de servidor.

If you do not want to stun / pause the virtual machine you can set snapshot.maxIterations to 20 (or higher). This means vSphere will do more tries (iterations) to commit the snapshot files. More information in this KB article.

Em seguida, ele descreve os riscos e desvantagens dessa abordagem.

Em segundo lugar, sugere:

Alternatively you can set snapshot.maxConsolidateTime to 60 seconds. This means you can accept a pause of the virtual machine for 60 seconds to do a synchronous consolidate. This is often a better option than wait for the snapshot file grow so big the virtual machine will require to be stunned for a much longer time.

Mas eu não sei a diferença entre "stun" e "pause".

E por último:

ESXi 4.1 has a update which added parameter snapshot.asyncConsolidate.forceSync = “FALSE” which needs to be added to the VMX file. This setting disables synchronous consolidate and the virtual machine will never be stunned. More info in this KB.

Ele não descreve as possíveis desvantagens dessas soluções, mas presumo que haja algumas, senão elas seriam padrão.

Ainda não verifiquei se esses parâmetros ou soluções ainda são relevantes na v5.

ATUALIZAÇÃO: A Veeam recomendou que fizéssemos as alterações mencionadas acima, conforme listado neste KB, que é relevante para a v4 e v5 do ESXi. Ao remover um instantâneo, as máquinas virtuais param de responder por mais de 30 minutos (2039754)

UPDATE2: Estamos fazendo essas alterações de configuração hoje e reiniciando o host, pois é mais barato e mais rápido do que esperar pelo cache. Em seguida, monitoraremos por alguns dias para ver se isso é o único a resolvê-lo para nós.