4 votos

Cómo evitar que VMWare aturde a un cliente durante la creación de imágenes con Veeam

Recientemente nuestro servidor MySQL ha sido "va a desaparecer" (es decir. la conexión del cliente cae). Después de semanas de intentar cosas diferentes (como el ajuste de tamaño de paquete), hemos descubierto que nuestro Veeam imágenes de copias de seguridad que utilice la API de VMWare instantánea y copia de la vmdks etc.

Estamos utilizando ESXi 5 con un Centos 6.4 invitado, correr (muy mucho) solo MySQL 5.1.69-log.

El cambio que parecía iniciar este problema fue el aumento de la física, tamaño de disco de 300 GB, de alrededor de 100, y el tamaño de la huésped del sistema de ficheros a utilizar la mayor parte de la nueva capacidad. Desde que el disco se incrementó, hemos estado recibiendo estos problemas durante las copias de seguridad, probablemente debido al aumento del tiempo necesario para realizar la instantánea de funciones relacionadas.

Los nuevos discos son 2x300GB Gen8 15k SAS en raid 1. Los viejos discos habría sido similar, sólo que más pequeño. El objetivo de la Veeam proceso es un ReadyNAS más de un 1 gb dedicado ethernet (es decir, separada de la oficina general de tráfico).

El anfitrión es una HP DL380P de la torre:

==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)

Mi "chico" ha hecho un par de retoques a la Veeam config incluyendo saltar bloques vacíos (la mayoría de el nuevo disco está vacío), pero esto no parece ayudar en todo.

Veeam no han sido de mucha ayuda, diciendo: "reiniciar el destino" o "sólo tiene que utilizar las Api de VMWare".

Creo que la "stun" significa que la máquina virtual, simplemente se congela por un tiempo (unos 30 segundos), a continuación, continúa normalmente.

VMWare.ejemplo de registro:

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

Así que mi problema tiene dos soluciones posibles:

  1. Es allí una manera de prevenir o reducir la "impresionante" de VMWare invitado durante la toma de imágenes.

  2. Es allí una manera de reducir el impacto de la aturdimiento en MySQL o la red virtual o Centos.

7voto

Tina Puntos 21

Este es un servidor ProLiant de HP que se ejecuta con una Smart Array RAID controlador sin un Flash-copia de módulo de caché.

Como resultado, usted no tiene el caché de escritura (o caché de lectura), y las operaciones, como las instantáneas de máquinas virtuales va a sufrir. Usted ha experimentado el efecto de este. La configuración actual no es adecuado para la mayoría de las cargas de trabajo, especialmente de virtualización.

Su mejor opción es simplemente comprar un módulo de caché y de la batería/FBWC; HP partes 631681-B21, 631679-B21, o 631069-B21.

Esto acelerará el rendimiento y eliminar el problema que estamos viendo.

Vea también:

FBWC, y el Cero de la Memoria (ZM) Controlador RAID HP DL360p

BBWC: en teoría una buena idea, pero tiene una vez guardado los datos?

¿Cuál es el módulo de memoria en una tarjeta RAID necesario para que?

1voto

scipilot Puntos 121

Respondiendo a mi propia pregunta de investigación. (Sólo voy a aceptar mi propia respuesta si uno de estos enfoques que realmente funciona y es antes de que alguien más la sugerencia.)

Esta (la más antigua) artículo ¿cuáles SON LOS PELIGROS DE las INSTANTÁNEAS Y CÓMO EVITAR? menciona algunas de las posibles causas y tres medidas preventivas. Es interesante que se menciona cómo el problema del mismo modo afecta a MS SQL Server y otros productos de servidor.

Si usted no desea stun / pausar la máquina virtual puede establecer instantánea.maxIterations a 20 (o más). Esto significa vSphere va a hacer más pruebas (iteraciones) para cometer los archivos de instantáneas. Más información en este artículo de KB.

Luego pasa a describir los riesgos y desventajas de este enfoque.

En segundo lugar, se sugiere:

Alternativamente, usted puede establecer instantánea.maxConsolidateTime a 60 segundos. Esto significa que usted puede aceptar una pausa de la máquina virtual para 60 segundos para hacer una sincrónico consolidar. Esto es a menudo una mejor opción de esperar a que el archivo de instantánea de crecer tan grande que la máquina virtual requieren para ser sorprendido por un tiempo mucho más largo.

Pero no sé la diferencia entre "stun" y "pausa".

Y por último:

ESXi 4.1 tiene una actualización que se añadió el parámetro la instantánea.asyncConsolidate.forceSync = "FALSO" que necesita ser añadido para el archivo VMX. Esta configuración deshabilita sincrónica y consolidar la máquina virtual nunca podrá ser aturdidos. Más info en este artículo de KB.

No se describen los posibles inconvenientes con estas soluciones, pero me gustaría presumir hay algunos que, de lo contrario se estaría predeterminado.

Todavía no he comprobado si estos parámetros o soluciones son todavía relevantes en v5.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: