Hola que tal, como estais? Soy Jose Maria Gris y como cada miercoles estoy aqui con vosotros.
Andamos un poco de cráneo preparando las pruebas que queremos hacer con Cloudarray con una serie de amigos que se han ofrecido a colaborar es en los laboratorios. Si eres de Barcelona y deseas colaborar, no dudes en ponerte en contacto con nosotros a traves de mi mail.
Hoy os vengo a comentar una situación curiosa que se me ha dado en una instalación. Esta instalación ha sido trasladada de CPD hace unos días y ha tenido una reconfiguración. Todo funciona perfectamente pero tenemos un warning a nivel de cluster “ha initiated a failover action in cluster”.
Me llaman y me dicen “oye, a pesar de reiniciar los agentes del HA de los Host, no desaparece el mensaje, es más, hemos reiniciado los host y tampoco”.
Bueno, no siempre la solución viene por el mismo lado, esta es una de las grandezas de nuestra profesión, que “así se solventaba”, pero en este caso no.
La respuesta es muy sencilla. Editamos las propiedades del Cluster y deshabilitamos el HA. Cuando está todo en su sitiio, volvemos a habilitar el HA y forzamos a los host a reconfigurarlo si es preciso. El mensaje ha desaparecido.
Bueno, me vuelvo a la task force que tenemos temas que tratar. Un saludo a todos.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.
Hola amigos, soy Florián Murillo y hablaremos del Failover Coordinator, una figura fundamental en un cluster HA de vSphere.
En un cluster HA, los hosts adquieren, como ya sabemos, un rol especifico, o primary host o secondary host.
Para identificar que rol tiene cada host, en noviembre publiqué un script en PowerCLI v.4.0 para identificar los primary host y los secondary host.
En vSphere uno de los primary host tiene una responsabilidad especial, posee el rol de Failover Coordinator, es decir, que es el responsable de seleccionar en que host se levantarán las VM encendidas al caer el host donde se ejecutan.
Este rol se asigna al azar, entre los primary host, además, cuando cae el host que posee este rol, uno de los restantes primary host adquiere este rol con un algoritmo de selección aleatoria.
Si revisamos el archivo /var/log/vmware/aam/aam_config_util_monitornodes.log vemos que el host con el rol Failover Coordinator se le denomina también Master Primary.
Hola, soy Miguel Angel Alonso y aquí estoy con vosotros como cada martes para contaros algo nuevo sobre la virtualización.
Lo primero de todo es felicitaros el año a todos nuestros lectores y a mis compañeros del Blog.
Hoy hablaremos sobre un nuevo Software que lanza Symantec para mantener el zero downtime en las aplicaciones que deseemos dentro de nuestro entorno de virtualización de VMware ( sin la necesidad de Fault Tolerance) o para aquellos clientes que hayan comprado versiones de VMware vSphere donde Fault Tolerance no venga incluido.
Lo mejor de todo es que funciona con las aplicaciones más conocidas (SQL, Oracle, SAP, etc…..) y además se integra de forma embebida dentro de la interfaz de VMware vSphere como parte de este (plug-in).
Symantec ApplicationHA es una solución de disponibilidad fácil de usar para entornos virtuales que ofrece visibilidad y control de aplicaciones. Está basada en la tecnología Veritas Cluster Server líder del mercado y ofrece disponibilidad de aplicaciones en coordinación con VMware HA. Symantec y VMware funcionan en conjunto para ayudar a los clientes a trasladar las aplicaciones fundamentales de la empresa a equipos virtuales de VMware.
Aquí os muestro algunas de sus características más importantes:
Visibilidad y control de las aplicaciones que se ejecutan en equipos virtuales desde la consola vCenter.
Detección de errores y recuperación de las aplicaciones que se encuentran dentro de los equipos virtuales.
Compatibilidad completa con funciones clave de VMware, como vMotion, DRS, DPM, etc.
Recuperación coordinada con VMware HA.
Sólo se necesitan unos clics para la instalación remota de la solución en un grupo de equipos virtuales.
Detección y configuración automática.
Compatibilidad heterogénea de sistemas operativos invitados, incluidos Windows y Linux.
Visibilidad y control de aplicaciones de varios niveles que se ejecutan en equipos virtuales y físicos, así como en sistemas operativos.
Compatibilidad inmediata para una amplia gama de aplicaciones empresariales, como SQL, Exchange, Oracle, SAP, etc.
Solución eficaz basada en la tecnología Veritas Cluster Server líder del mercado.
Ventajas clave:
Alta disponibilidad de aplicaciones en equipos virtuales.
Análisis de la causa raíz más rápido con visibilidad de aplicaciones desde vCenter.
Beneficios más rápidos gracias a la compatibilidad inmediata de aplicaciones, la configuración automática, la instalación remota, etc.
Menor complejidad operativa mediante una solución para sistemas operativos invitados y tipos de aplicaciones.
Capacidad para aprovechar la virtualización sin olvidar los acuerdos de nivel de servicio.
Virtualización de aplicaciones fundamentales para la empresa con confianza.
Los requisitos del sistema son:
a) Red Hat Enterprise Linux 5(x)
b) Windows 2003 Server SP2 x86 y x64
c) Windows 2008 Server SP2 x86 y x64
d) Windows 2008 R2
Aquí os dejo un video de como instalar y configurar esta genial aplicación de Symantec para VMware. Bueno, esperando que os haya gustado, me despido de vosotros hasta la semana que viene.
Que paséis muy buenos días y os deseo a todos un feliz 2011!!!!!!!!
Hola amigos, soy Florián Murillo, a veces me pregunto si todos los host del cluster tienen la misma versión y si todas las VM tienen la misma versión de la placa base.
Recordar que la versión de la placa base virtual define que dispositivos podemos entregar a la VM y que propiedades tiene la blaca base, por ejemplo la ampliación de discos VMDK en caliente o el añadir RAM y vCPUs en caliente.
En un entorno pequeño lo sabemos de memoria, tardamos un segundo en contestar, pero en un entorno mediano o grande no podemos responder tan rápidamente con total garantía.
Actualmente es motivo de problema, intentar añadir un host v.4.0 en un switch distribuido creado en la versión v.4.1, además las auditorías de seguridad dependen de la versión del host (VI3 o vSphere 4), por tanto ya no es una información “curiosa” tener esta información, sino una necesidad para evitar problema y cumplir normativas de seguridad, o sea, disminuir el riesgo del negocio ante problemas de seguridad.
Por tanto, he creado un script que os ayudará a conocer el estado de vuestros sistemas, espero que os ayude:
Hola amigos, soy Florián Murillo y supongo que alguna vez os habéis preguntado, como yo ¿quien tiene el rol primary en mis clusters HA?
Solo recordaros que en un cluster VMware HA los cinco primeros host que entramos en el cluster cogen el rol de primary y el resto tienen el rol secondary.
Los host que tienen el rol primary, tienen una base de datos con una copia del inventario, por tanto ellos saben que VM están ejecutandose en cada host, esto es básico, ya que es esta información la que se utiliza para levantar VM cuando cae un host.
En un escenario completo, con más de un chasis de blades, me he de asegurar que no “caigan” todos los host con rol primary en el mismo chasis, porque VMware HA no funcionaría si cae este chasis.
Para averiguar que host disfruta del rol primary en un cluster, os adjunto este simple script en PowerCLI que listará de forma sencilla el nombre de los hosts que tienen el rol primary.
Para entornos con pocas tarjetas de red (dos o menos), es posible usar y configurar la red de VMotion , no solo para el trafico de migración de máquinas virtulaes con VMotion, sino también para poder mandar el heartbeat de vSphere VMware HA.
Para mandar el heartbeat de VMware HA por la red de VMotion es preciso cambiar las opciones avanzadas de VMware High Availability (HA). En la mayoría de los entornos, los settings de VMware HA no son necesarios cambiarlos.
das.allowVmotionNetworks = “valor”, permite considerar la red de VMotion para usarla con VMware HA, donde la palabra “valor” representa el valor “true” o “false”.
Esta configuración permite a un servidor ESX/ESXi con una sola tarjeta de red para la red de gestión del servidor, utilizar la red de VMotion como red de backup para mandar los heartbeat del cluster VMware HA.
Este episodio #22 describe como configurar las opciones avanzadas de VMware HA para poder utilizar la red de VMotion y usarla como backup para mandar el heartbeat HA en caso de caída de la red de gestión del Service Console:
VMware HA garantiza el re-inicio de las maquinas virtuales en caso de una caída o fallo del servidor físico vSphere ESX. VMware HA es configurado, gestionado desde el servidor de vCenter.
Antes de configurar VMware HA, deberías chequear que todas las máquinas virtuales, pueden encenderse en los nodos que vayan a formar el clúster. Recuerda que el acceso a recursos comunes como LUNs y redes virtuales para las máquinas virtuales es vital.
El 99,9% de los errores con VMware HA vienen derivados de una mala configuración del servidor DNS.
Asegúrate que tu servidor DNS funciona perfectamente y que puedes hacer ping por nombre corto, FQDN, alias y dirección IP desde todos los servidores ESX y desde el VirtualCenter.
Todos los servidores ESX que forman parte del cluster HA deben ver las LUNs donde están las maquinas virtuales. Recuerda que las maquinas virtuales que estén en discos locales de los servidores ESX, no serán restauradas en caso de failover.
Configura un teaming en la conexión del Service Console para dotar de redundancia la red de heartbeat.
Recuerda que HA no sustituye a productos de clustering como por ejemplo Microsoft Clustering Services (MSCS) ya que en VMware HA, aunque es mínimo, hay downtime de las maquinas virtuales.
VMware recomienda tener dos tarjetas de red físicas dedicadas para el control del latido del clúster (heartbeat).
Asimismo, el uplinks vmnic2 y vmnic0, en mi caso, deberían estar conectados a dos switches físicos diferentes. Esta es la única manera de no tener ningún punto de fallo, en el componente de la red.
Recuerda que no es necesario tener dos Service Conosle port, aunque si es recomendable para un clúster HA en producción.
Si te decides por la configuración de dos switches físicos con un uplink entre el switch físico y el switch virtual, debes cambiar el parámetro das.failuredetectiontime. Para cambiar este parámetro, entra en las opciones avanzadas (Advance Options) y entra el parámetro siguiente:
Host failures, determina el número de fallos de tus host ESX y que tu cluster HA puede tolerar.
Admission control, es una política usada por VMware HA para asegurarse que el failover pueda ocurrir en caso de caída de uno de los host ESX.
Recuerda que aunque es posible crear VMware HA clusters de hasta 32 nodos, el host failure no puede ser mayor de 4. La razón es porque en VMware HA solo puede haber un máximo de 5 nodos con el role primario y con este setting VMware HA se asegura que siempre un nodo primario este “levantado”.
Para editar las opciones de host failures y admission control, debes de hacer clic con el botón derecho sobre el clúster y seleccionar Edit Settings:
Recuerda que el valor por defecto de Isolation Response, en VMware ESX 3.5 udpate4, es de Power Off, es decir, en caso de aislamiento de uno de los nodos del clúster (perdida del heartbeat) las máquinas virtuales se apagaran, para que estas puedan encenderse en otro nodo del clúster HA.
Restart Priory y Isolation Response son configuraciones a nivel de clúster aunque esta configuración puede también ser modificada a nivel de máquina virtual, en cuyo caso tendrá preferencia sobre el setting a nivel de clúster.
Se han mejorado y corregido muchas e importantes funcionalidades en HA aunque la mas importante yo diría que es que ahora es posible borrar las opciones avanzadas de HA, opciones que dicho sea de paso fueron introducidas con el update 2. Suena paradójico, verdad!.
Otro bug que ha sido solucionado con esta actualización y que fue muy comentado en los foros de VMware, fue el hecho de que las maquinas no se migraran con VMotion cuando se ponía el host en modo mantenimiento, que es lo que realmente debería ocurrir en caso de poner un host en modo mantenimiento.
Para conseguir el update 3 del VirtualCenter 2.5 pincha aquí. (Requiere login)
Como nota final, no olvides que con esta actualización los plugins de Update Manager y VMware Converter también serán actualizados a la última versión.
Lamentablemente el soporte de VMware Converter para conversiones Linux es aun experimental.
Marathon Technologies, que ya ofrecía una de las primeras soluciones de alta disponibilidad para XenServer en máquinas virtuales, ahora ha logrado integrar en mayor medida la solución de HA con el Hypervisor de Citrix.
Las dos empresas están trabajando para incluir Marathon everRun VM en la configuración XenServer e integrar el everRun Availability Center dentro XenCenter para que transparente se sincronice la configuración de HA en cada consola.
No está claro si esta integración será proporcionado por una versión especial de XenServer que solo Marathon Technologies puede revender (ya que la empresa tiene un acuerdo OEM), o si será un solución out of the box para cada solución XenServer que se venda a clientes en todo el mundo.
Descubre y domina la nueva versión de VMware vSphere™ 5 y aprovéchate de hasta un
20% de descuento al comprarlo online.
Regístrate y
recibe un capitulo de nuestro nuevo libro totalmente gratuito
Nuevo Site Recovery Manager 4 en español Consigue una copia gratuita del eBook
