9·1·1 | Identity Source
A falta de una definición mas detallada diré que el identity Source no es mas que un "vinculo" entre un origen de datos, en este caso un directorio activo, LDAP, NIS o Sam local y SSO.
9 | Instalación
En los siguientes apartados publicare los procedimientos de instalación de componentes de VMware que me vaya encontrando en el día a día. Remarcando las incidencias que me encuentre por el camino.
9·1 | Single Sign-On
VMware vCenter Single Sign-On
Con la nueva versión 5.1 aparece un componente nuevo, vCenter Single Sign-on, es un componente de autenticación centralizada y simplifica la autenticación de los usuarios en las diferentes capas de vCenter.
Con SSO se evita el Linked Mode y es posible configurar múltiples dominios aun sin relación de confianza entre ellos y usuarios locales, de este modo podremos validarnos desde un mismo cliente vSphere en diferentes servidores vCenter con credenciales de diferentes dominios y directorios dependiendo de los permisos de cada instancia. También acepta OpenSource (NIS, LDAP).
Esta pensado para el Cloud y MultiSites como se puede ver en la siguiente imagen.
Imagen. Diagrama de ejemplo SSO Multisite, fuente: VMware Blogs
SSO se instalara por defecto en una Base de Datos local de SQL Express aunque por supuesto se puede crear y especificar una en un SQL Server de la organización.
Con la nueva versión 5.1 aparece un componente nuevo, vCenter Single Sign-on, es un componente de autenticación centralizada y simplifica la autenticación de los usuarios en las diferentes capas de vCenter.
Con SSO se evita el Linked Mode y es posible configurar múltiples dominios aun sin relación de confianza entre ellos y usuarios locales, de este modo podremos validarnos desde un mismo cliente vSphere en diferentes servidores vCenter con credenciales de diferentes dominios y directorios dependiendo de los permisos de cada instancia. También acepta OpenSource (NIS, LDAP).
Esta pensado para el Cloud y MultiSites como se puede ver en la siguiente imagen.
SSO se instalara por defecto en una Base de Datos local de SQL Express aunque por supuesto se puede crear y especificar una en un SQL Server de la organización.
1·5·3 | Datastore Heartbeating
Datastore Heartbeating
Como ya se ha comentado antes todos los hosts del cluster intercambian heartbeats con los datastores para confirmar que estan activos.
vCenter seleccionara un minimo de dos y un maximo de cinco datastores, a ser posible de diferentes storages, solo podra seleccionar datastores accedidos por al menos dos hosts del cluster intentando maximizar el numero de hosts que tienen acceso a ellos.
Todo esto es configurable de forma manual, tambien se puede modificar el numero de datastores a seleccionar por defecto (entre 2 y 5) con el comando:
das.heartbeatdsperhost
y especificando como valor el numero de datastores.
Imagenes. vCenter da la opcion de seleccionar manualmente los datastores aunque de forma automatica ha seleccionado dos de diferentes storages (SAN/iSCSI y NAS) accedidos por todos los hosts del cluster.
Como ya se ha comentado antes todos los hosts del cluster intercambian heartbeats con los datastores para confirmar que estan activos.
vCenter seleccionara un minimo de dos y un maximo de cinco datastores, a ser posible de diferentes storages, solo podra seleccionar datastores accedidos por al menos dos hosts del cluster intentando maximizar el numero de hosts que tienen acceso a ellos.
Todo esto es configurable de forma manual, tambien se puede modificar el numero de datastores a seleccionar por defecto (entre 2 y 5) con el comando:
das.heartbeatdsperhost
y especificando como valor el numero de datastores.
Imagenes. vCenter da la opcion de seleccionar manualmente los datastores aunque de forma automatica ha seleccionado dos de diferentes storages (SAN/iSCSI y NAS) accedidos por todos los hosts del cluster.
1·5·2 | Host Monitoring
Host Monitoring (Monitorización de hosts)
Una vez por segundo se monitoriza el estado de los hosts mediante intercambios de Heartbeats entre los hosts esclavos y el host maestro, cuando este detecta la falta de heartbeats de alguno de los hosts realiza un test de la conexión a la red de administración de este. El test consiste en enviarle pings a su direccion IP y comprobar si el intercambio de heartbeats entre el supuesto host fallido y los datastores a cesado.
Si ninguno de los tests concluye satisfactoriamente el host es declarado en fallo, en este caso el host maestro reinicia las VMs ubicadas en el host en fallo a otros hosts del cluster HA.
En el caso de que el test de intercambio de heartbeats con el datastore es satisfactorio, el host maestro asume que ha quedado aislado de la red de administración o en una red dividida, envia una alerta a vCenter y continua monitorizando tanto al host aislado como a sus VMs.
Cuando un host queda aislado de la red de administración intentara acceder a la red de aislamiento del cluster mediante pings, de no conseguirlo, se declarara a si mismo en aislamiento y el host maestro comprobara la configuración definida en el cluster HA.
Configuración de comportamiento de las VMs en caso de que el host se declare aislado (Host Isolation Response).
Una vez por segundo se monitoriza el estado de los hosts mediante intercambios de Heartbeats entre los hosts esclavos y el host maestro, cuando este detecta la falta de heartbeats de alguno de los hosts realiza un test de la conexión a la red de administración de este. El test consiste en enviarle pings a su direccion IP y comprobar si el intercambio de heartbeats entre el supuesto host fallido y los datastores a cesado.
Si ninguno de los tests concluye satisfactoriamente el host es declarado en fallo, en este caso el host maestro reinicia las VMs ubicadas en el host en fallo a otros hosts del cluster HA.
En el caso de que el test de intercambio de heartbeats con el datastore es satisfactorio, el host maestro asume que ha quedado aislado de la red de administración o en una red dividida, envia una alerta a vCenter y continua monitorizando tanto al host aislado como a sus VMs.
Cuando un host queda aislado de la red de administración intentara acceder a la red de aislamiento del cluster mediante pings, de no conseguirlo, se declarara a si mismo en aislamiento y el host maestro comprobara la configuración definida en el cluster HA.
Configuración de comportamiento de las VMs en caso de que el host se declare aislado (Host Isolation Response).
1·5 | vSphere HA
HA
Sin lugar a dudas, para mi es una de las grandes maravillas de la virtualización. Acostumbrados al servidor físico monosistema y al cluster de servicios implementado para reiniciar una aplicación o recurso en el caso de que uno de los servidores caiga.
HA permite reiniciar servidores virtuales completos en segundos/minutos en caso de caída de uno de los hosts.
Básicamente HA permite crear clusters de múltiples hosts ESXi para recuperaciones rápidas y automáticas de VMs sin necesidad de software o servicios en las mismas.
Imagen. Esquema de fallo de host y reinicio de sus VMs a los restantes del cluster.
También puede resetear VMs en caso de que estas dejen de responder mediante (VM Monitoring)
La cosa se pone aun mas interesante cuando se combina con DRS (Distributed Resource Scheduler), que permite balancear VMs en caliente mediante vMotion en función de la carga de estas dentro de los Pools de recursos, de las reservas establecidas, de las políticas configuradas, reglas de afinidad-antiafinidad.
Por poner un ejemplo, puedes crear una regla para que dos DCs esten siempre en hosts separados y que en caso de fallo de uno de ellos siempre quede uno sin interrupción. O que los servidores mas críticos estén siempre en los hosts mas libres de carga.
Con HA, DRS y un buen planeamiento se pueden establecer configuraciones de alta disponibilidad antes inalcanzables.
En los siguientes apartados intentare que se entienda como funciona HA (si es que yo mismo lo he llegado a entender).
Sin lugar a dudas, para mi es una de las grandes maravillas de la virtualización. Acostumbrados al servidor físico monosistema y al cluster de servicios implementado para reiniciar una aplicación o recurso en el caso de que uno de los servidores caiga.
HA permite reiniciar servidores virtuales completos en segundos/minutos en caso de caída de uno de los hosts.
Básicamente HA permite crear clusters de múltiples hosts ESXi para recuperaciones rápidas y automáticas de VMs sin necesidad de software o servicios en las mismas.
Imagen. Esquema de fallo de host y reinicio de sus VMs a los restantes del cluster.
También puede resetear VMs en caso de que estas dejen de responder mediante (VM Monitoring)
La cosa se pone aun mas interesante cuando se combina con DRS (Distributed Resource Scheduler), que permite balancear VMs en caliente mediante vMotion en función de la carga de estas dentro de los Pools de recursos, de las reservas establecidas, de las políticas configuradas, reglas de afinidad-antiafinidad.
Por poner un ejemplo, puedes crear una regla para que dos DCs esten siempre en hosts separados y que en caso de fallo de uno de ellos siempre quede uno sin interrupción. O que los servidores mas críticos estén siempre en los hosts mas libres de carga.
Con HA, DRS y un buen planeamiento se pueden establecer configuraciones de alta disponibilidad antes inalcanzables.
En los siguientes apartados intentare que se entienda como funciona HA (si es que yo mismo lo he llegado a entender).
1·5·1 | Operating HA
Funcionamiento de HA (High Availability)
Al crear un cluster HA se establece una jerarquia entre los hosts que lo forman, uno de ellos es designado como “Master host” y el resto como "Slave Host).
Host Maestro:
Es el encargado de comunicarse con el servidor vCenter, tambien se encargara de monitorizar el estado de salud del resto de hosts (Slaves) y sus VMs.
El host maestro ha der ser capaz de detectar y diferenciar de forma correcta los diversos tipos de errores que pueden afectar a un host ESXi. Asi como diferenciar entre fallos y aislamientos de red.
Independientemente del rol de cada uno, al integrase en un cluster HA se instala un agente (HA Agent) en cada uno de los hosts, el agente es el encargado de permitir la comunicacion (hablar) entre ellos.Al habilitar HA en un cluster o agregar un host a uno ya habilitado todos ellos se comunican y eligen al Host maestro. La eleccion no es arbitraria, si uno de los hosts tiene un numero mayor de datastores contara con ventaja en la eleccion.
Las funciones del Host Maestro son:
-Gestionar el inventario de hosts y VMs del cluster.
-Monitorizar el estado de salud del resto de sus esclavos, si uno falla o sufre aislamiento se encarga de identificar que VMs deben ser reiniciadas. Tiene en cuenta las siguientes condiciones:
-Un fallo de hardware apaga uno de los hosts.
-Un fallo o incidencia (desconexion) en la electronica de red aisla uno de los hosts.
-Un host deja de comunicarse con el host maestro, sea cual sea la causa.
-Se comunica con vCenter y permite la configuracion del cluster informando del estado de salud del mismo.
-Monitoriza el estado de salud de las VMs del cluster encargandose del reinicio y reubicacion de estas en caso de fallo.
Las funciones del Host esclavo son:
-Ejecucion de las VMs que tiene designadas e informar al host maestro de su estado de salud.
-Intercambiar Hearthbeats con el host maestro y con al menos uno de los datastores.
Las funciones de vCenter respecto a HA son:
-Informar mediante vSphere Client de la jerarquia y estado de los agentes HA de los hosts (vSphere HA host state), visible en la pestaña Summary o Datacenter and cluster > Hosts.
-Mantener la comunicacion con el host maestro y servir de puente para la configuración del cluster.
Al crear un cluster HA se establece una jerarquia entre los hosts que lo forman, uno de ellos es designado como “Master host” y el resto como "Slave Host).
Host Maestro:
Es el encargado de comunicarse con el servidor vCenter, tambien se encargara de monitorizar el estado de salud del resto de hosts (Slaves) y sus VMs.
El host maestro ha der ser capaz de detectar y diferenciar de forma correcta los diversos tipos de errores que pueden afectar a un host ESXi. Asi como diferenciar entre fallos y aislamientos de red.
Independientemente del rol de cada uno, al integrase en un cluster HA se instala un agente (HA Agent) en cada uno de los hosts, el agente es el encargado de permitir la comunicacion (hablar) entre ellos.Al habilitar HA en un cluster o agregar un host a uno ya habilitado todos ellos se comunican y eligen al Host maestro. La eleccion no es arbitraria, si uno de los hosts tiene un numero mayor de datastores contara con ventaja en la eleccion.
Las funciones del Host Maestro son:
-Gestionar el inventario de hosts y VMs del cluster.
-Monitorizar el estado de salud del resto de sus esclavos, si uno falla o sufre aislamiento se encarga de identificar que VMs deben ser reiniciadas. Tiene en cuenta las siguientes condiciones:
-Un fallo de hardware apaga uno de los hosts.
-Un fallo o incidencia (desconexion) en la electronica de red aisla uno de los hosts.
-Un host deja de comunicarse con el host maestro, sea cual sea la causa.
-Se comunica con vCenter y permite la configuracion del cluster informando del estado de salud del mismo.
-Monitoriza el estado de salud de las VMs del cluster encargandose del reinicio y reubicacion de estas en caso de fallo.
Las funciones del Host esclavo son:
-Ejecucion de las VMs que tiene designadas e informar al host maestro de su estado de salud.
-Intercambiar Hearthbeats con el host maestro y con al menos uno de los datastores.
Las funciones de vCenter respecto a HA son:
-Informar mediante vSphere Client de la jerarquia y estado de los agentes HA de los hosts (vSphere HA host state), visible en la pestaña Summary o Datacenter and cluster > Hosts.
-Mantener la comunicacion con el host maestro y servir de puente para la configuración del cluster.
El Blog
Primero de todo he de aclarar que no soy ni me considero un experto en VMware o virtualización en general, tan solo soy un apasionado de la virtualización (especialmente con VMware), técnico de sistemas que se enfrenta diariamente a instalaciones y que le toca apagar fuegos en diferentes escenarios (clientes) con entornos virtuales dispares.
Este Blog es un intento de aclarar algunas dudas conceptuales y teóricas sobre la virtualización con VMware y guia para aplicar algunas configuraciones, es una mezcla de notas tomadas en instalaciones, laboratorios, configuraciones de entornos SAN y virtualización así como adaptaciones de artículos leídos, traducciones, etc.. También hay mucho de manuales de fabricantes, buenas prácticas, algunas implementadas y comprobadas y otras no y de conocimientos adquiridos en los cursos oficiales de VMware para las certificaciones VCP obtenidas.
Por descontado no me adjudico la autoría de mucho de lo aquí escrito ya que gran parte ha sido extraído de otras fuentes, como por ejemplo la documentación oficial de VMware y otros.
Pretende ser una recopilación de información en español y guia online de consulta particular que he compartido por si a alguien le puede ser de utilidad.
En el panel de la izquierda he creado etiquetas que redirigen a las entradas del Blog, a modo de indice se puede acceder a los contenidos.
Dado que no soy ningún erudito en la materia y seguro que habrán multitud de gazapos y correcciones por hacer, dejo habilitada la opción de comentar en esta pagina, no dudéis en comentar cualquier cosa que veáis mal o se pueda mejorar que lo iré modificando en las paginas pertinentes.
Por supuesto que cualquiera puede participar y enviar ya sea por mail o comentarios en esta entrada buenas prácticas configuradas o cualquier cosa que pueda ser de interés, lo adaptare y citare al autor.
Suscribirse a:
Entradas (Atom)