Es preciso aclarar que el adjetivo "inesperados" se refiere a dos perspectivas: la del administrador de VMWare y la propia perspectiva del vCenter. El ESX es perfectamente consciente de que ha tomado un Snapshot.
VCB (VMWare Consolidated Backup) es una potente herramienta, especialmente si se combina con VMs que soportan VSS (Microsoft Volume Shadow Service). La idea consiste en "congelar" el I/O a la Base de Datos (SQL Server, Exchange...) mientras la máquina sigue dando servicios a los usuarios. Este trabajo lo realiza VSS a través de VMWare Tools, que instala en la máquina virtual lo que en arquitectura VSS se denomina "provider". En ese momento es cuando el ESX toma el Snapshot.
Un poco de arquitectura VSS.
La arquitectura de VSS, resumida, consta de cuatro bloques principales. Los providers, los writers, los requestors y el propio servicio de VSS. Como se puede ver, es una arquitectura muy flexible y modular. Cada programa que precisa hacer peticiones al VSS puede tener un requestor propio, cada recurso de storage tiene un provider y cada aplicación o elemento sobre el que VSS puede operar dentro del sistema, tiene su propio writer.
Cuando una herramienta de backup quiere realizar una copia coherente de una base de datos, su requestor envía una solicitud al VSS para que realice un freeze (congelación, parada) de la Base de Datos - se ejecutan previamente, si existe, el script pre-freeze.bat - y VCB pueda solicitar un Snapshot de la máquina virtual.
El ESX pone en marcha el Snapshot. En ese momento es cuando las herramientas de fabricante toman un snapshot en el sistema de almacenamiento (storage) que soporta las operaciones, suele ser un snapshot de la LUN que contiene el DataStore con esa VM coherente. Cuando el almacenamiento ha iniciado su snapshot (cuestión de pocos segundos), las herramientas de backup solicitan a VCB que elimine rápidamente el Snapshot de VMWare. VCenter ordena al ESX que el snap sea borrado, tras lo cual se ejecuta en la VM -si existe- el script post-thaw.bat y las operaciones en el nivel de la cabina de almacenamiento continúan mientras las VMs de producción siguen operando con normalidad.
En posteriores publicaciones trataré los scripts pre-freeze.bat y post-thaw.bat .
En todo este proceso, la capa superior es un script o una herramienta de fabricante que opera con scripts y recibe de los diversos elementos que intervienen, notificaciones del estado de ejecución de las tareas. Si se ha realizado el freeze, si se ha tomado el snapshor de VMWare, si se ha borrado, etcétera. Sobre esa información de estados, elaboran el log, por el que el administrador conoce qué ha sucedido durante el desarrollo de los trabajos automatizados.
Ante la notificación de un error, en el que el sistema informa de que no se ha podido congelar la máquina virtual, o no se ha podido tomar un snapshot de la misma, el administrador da el trabajo por perdido y examina el estado de las Tools y los servicios en las máquinas virtuales, para garantizar que la próxima ejecución concluye correctamente.
Pero es posible, que a pesar de que la notificación indique que no se ha tomado snapshot de VMWare, el snapshot sea detectado días después, cuando el impacto en el rendimiento de la máquina virtual es percibido por todos los usuarios del servicio. El administrador busca las causas de que la VM no responda siquiera a las peticiones ICMP mediante ping y cuando pulsa sobre el botón del snapshot manager, allí están; uno o varios snapshots tomados días atrás y que han crecido desproporcionadamente. Intentar borrarlos es una tarea de horas de espera bajo la presión de llamadas, correos e incluso, alguna que otra mirada amenazante. Mientras la máquina virtual sigue sin responder.
¿Qué ha sucedido?
El snapshot de VMWare es un proceso asíncrono, en el que el vCenter solicita al ESX Server que realice el trabajo. El Servidor vCenter espera entonces un tiempo a que el ESX le responda, ese tiempo está pre-configurado, de modo que en máquinas virtuales con especial carga transaccional, el ESX se demora más tiempo del que el vCenter espera a la conclusión de la tarea, el vCenter notifica entonces a la herramienta que encargó el snapshot que no se hizo por timeout, la tarea así lo indica en el log y concluye con error. Esto es falso, porque mientras tanto, el ESX sigue congelando la máquina y tomando el snapshot. Como nadie lo borra porque ya no se le espera, permanece allí hasta que es eliminado manualmente.
Si nadie advierte que el snapshot existe, en poco tiempo - especialmente en esas máquinas de alta carga de transacciones - el rendimiento de la misma empezará a caer en picado. Especialmente si todo este proceso pasa inadvertido y ocurre más de una vez, dejando varios snapshots inesperados en el sistema.
¿Cual es la solución?
Lo primero es ampliar los tiempos preconfigurados de timeout en el vCenter Server, dando más tiempo al ESX para que acabe correctamente en esas máquinas más cargadas de transacciones. Lo segundo es monitorizar los ESX mediante scripts, para detectar y eliminar lo más tempranamente posible esos snapshots. En sucesivos artículos veremos esto en más detalle.
A convention of pelicans on the Salton Sea and a view of the sea and mountains from the shores of the nearby State Park. Although the resort is isolated, its advantage is that is the only place where you get the winter-time benefits of desert living and also be close to the excellent birding area that is the Salton Sea. Love it Cheryl! You are amazing. Thank you for sharing this with us. New signoff? How about "see you in the sea"? Or, "see you under the sea"?
Posted by: viagra online | September 01, 2010 at 09:36 PM