Tema 4: VMVARE VSPHERE. EL ENTORNO DEL CLUSTER EN VSPHERE

Transcripción

1 Orense, Madrid D`Aribau, Barcelona Tema 4: VMVARE VSPHERE. EL ENTORNO DEL CLUSTER EN VSPHERE Parte 1 - Implementación del Cluster de vsphere Parte 2 - Configuraciones previas Parte 3 - Descripción de las propiedades del Cluster Parte 4 - Prueba de las funciones de un Cluster Vmware Parte 5 - Opciones avanzadas Formadores IT, Todos los derechos reservados. Prohibida su reproducción total o parcial.

2 Qué es un cluster Un clúster es un grupo de ordenadores unidos mediante la red, de forma que el conjunto trabaja como un único ordenador. Los clústeres son utilizados para dotar de mayor rendimiento y/o disponibilidad a los servicios que podría ofrecer un único ordenador. De un clúster se espera que presente combinaciones de los siguientes servicios: Alto rendimiento: Capacidad para realizar tareas complejas que requerirían grandes cantidades de hardware (memoria, cpu, red..) Alta disponibilidad: Capacidad para desvincular cualquier problema de hardware, energía o red que pueda afectar a un ordenador individual a la producción del servicio Balanceo de carga: Capacidad para repartir el volumen de trabajo entre los diferentes ordenadores que forman el clúster Escalabilidad: Capacidad para aumentar o reducir el número de ordenadores que forman el clúster en función de la carga de trabajo sin detener la producción del servicio Los clústeres permiten a las organizaciones incrementar su capacidad de procesamiento sin necesidad de utilizar supercomputadoras, tan sólo utilizando tecnología estándar, tanto en componentes de hardware como de software que pueden adquirirse a un costo relativamente bajo. Cluster de la NASA

3 Cómo funciona un Clúster en Vmware Vsphere Un Clúster de Vmware Vsphere es igual en términos a cualquier otro Clúster con la particularidad de servir únicamente servicios virtuales. Podemos definir un Clúster de Vmware Vsphere como un conjunto de Hosts ESX/ESXI relacionados entre ellos bajo una relación de confianza que comparten y complementan servicios propios de una infraestructura Vmware Vsphere. La idea de formar un Clúster en Vmware Vsphere es aumentar la disponibilidad de los servicios virtuales que brindan, realizar balanceo de carga entre los diferentes Hosts que forman el Clúster, dotar a la infraestructura virtual de escalabilidad entre los Hosts y procurar una tasa de consolidación alta con el máximo ahorro de energía. Distinguiremos varios componentes que forman un Clúster en Vmware Vsphere: Servicios clusterizados: Servicios que realiza Vmware Vsphere unicamente en un entorno de Clúster (HA, DRS, DPM, FT, EVC) Nodos: Servidores, Hosts ESX/ESXI, que forman el Clúster Almacenamiento compartido: Almacenamiento NAS o SAN (iscsi, NFS, FC) al que se conectarn los Hosts ESX/ESXI de manera simultanea. Heartbeats: Canal de comunicación entre servidores ESX/ESXI o máquinas virtuales para comprobar el estado de estos.

4 Tipos de Clúster en Vmware Vsphere Hay dos tipos de Clúster en Vmware Vsphere: Clúster de Hosts: Es el Clúster principal en un entorno de Vmware Vsphere. Los Hosts establecen una relación de confianza en la que comparten recursos y realizan servicios conjuntos (HA, DRS, DPM, EVC y FT) Clúster de Datastores: Es un tipo de Clúster introducido en la versión 5 de Vmware Vsphere en la que se crea una relación de confianza entre diferentes Datastores, con la intención de repartir carga entre ellos en función de velocidad de escritura/lectura y de capacidad de almacenamiento

5 Servicios y funciones de un Cluster en Vmware Vsphere Una infraestructura de Hosts ESX/ESXI bajo un entorno de Clústeres nos permite brindar los siguientes servicios: HA (High Availability): A través de este servicio podremos definir como queremos que se comporte el Clúster ante los fallos de Hosts o de máquinas virtuales. Podremos configurar el reinicio automático de las máquinas virtuales para cuando se detecte que éstas no están funcionando correctamente. O bien podremos definir que las máquinas virtuales de un Host colgado, apagado, con perdida de conexión de red o de almacenamiento pasen a ser controladas por otro Host funcional del Clúster DRS (Distributed Resource Scheduler): Este servicio permite la repartición de carga de trabajo entre los diferentes componentes de un Clúster. DRS realizará migraciones Vmotion de las máquinas virtuales entre los diferentes datastores o los diferentes Hosts de manera que éstos trabajen de manera equitativa. DPM (Distributed Power Management): Este servicio está destinado a aumentar la tasa de consolidación con el mayor ahorro de energía. DPM trabaja conjunto con el servicio DRS, permitiendo reunir las máquinas virtuales en un conjunto mínimo de Hosts, con la intención de apagar los que quedan libres y ahorrar energía eléctrica en los momentos de menor carga de trabajo.

6 EVC (Enhanced Vmotion Compatibility): Propone un conjunto de reglas en función de la afinidad de procesadores similares para aumentar la eficiencia y velocidad a la hora de realizar las migraciones Vmotion de las máquinas virtuales. FT (Fault Tolerance): Es el servicio de Tolerancia de Errores de Vmware. Las máquinas virtuales funcionando con FT correrán en dos Hosts ESX/ESXI de manera simultanea, evitando cualquier parada de las máquinas virtuales en el caso de fallo de alguno de estos Hosts.

7 Funciones y requisitos del HA Vsphere HA proporciona "Alta disponibilidad" para máquinas virtuales que residen en un Clúster. Los Hosts en un Clúster son monitorizados y en caso de fallo las máquinas virtuales serán reiniciadas en alguno de los otros Hosts que conforman el Clúster. Cuando se crea un Clúster con HA un único Host es definido como Master. Este Host se comunica con el Vmware Vcenter y monitoriza el estado de todas las máquinas virtuales. El Host master debe ser capaz de distinguir el tipo de error que se ha producido sobre una máquina virtual o un Host. La elección del Host Master se realiza de manera aleatoria, siendo el que tiene mayor número de Datastores diponibles el mejor candidato para ser Master. Si se produjera la caida del Host Master, alguno de los Hosts restantes que conforman el Clúster pasaría automáticamente a ser Master y declararía el Host, anteriormente Master, como fallido. Se puede configurar Vsphere HA para reaccionar ante un fallo de una máquina virtual o de un Host. Una máquina virtual se da como fallida cuando las Vmware Tools no son capaces de intercanviar Heartbeats con el Host Master. En este caso y según la configuración que le hayamos realizado al Clúster, la máquina virtual puede ser reiniciada para solventar el error. Un Host se da como fallido cuando este no puede intercambiar Heartbeats con el Host Master. En este caso el Host Master intentará forzar la comunicación del Host fallido con sus Datastores,a través de los llamados Datastore Heartbeats; en función del resultado se declarará uno de los siguiente fallos: Failover: Caida del Host ESX/ESXI por fallo de Hardware, Sistema Operativo, fallo de corriente o desconexión de las diferentes redes del Host Network Isolated: Perdida de conexión sobre un Host (Management Network) pero no sobre las máquinas virtuales que contiene. Para asegurar que hay suficientes recursos disponibles en el Cluster para proporcionar una protección ante el Failover de un Host y asegurar que las reservas de las máquinas virtuales, y los pools de recursos son respetados, Vmware Vsphere utiliza el llamado control de adminisión (Admision Control) El Control de Admisión impone reglas sobre el uso de recursos para asegurar la disponibilidad de recursos del Clúster ante el Failover de un Host. Para ello monitoriza las siguientes acciones: Arranque de las máquinas virtuales Migración de las máquinas virtuales entre pools de recursos Incremento de las reservas de CPU o memoria de una máquina virtual Cuando alguna de estas acciones realizadas ponga en entredicho la capacidad total del Clúster para asegurar la viabilidad del Failover, Vmware Vcenter nos prohibira la realización de la acción. Podremos configurar la capacidad del control de admisión de 3 maneras diferentes: Host Failures Cluster Tolerates Admission Control Policy: Se asegura la capacidad del Failover a través del calculo del llamado Slot Size. El Slot Size es la mayor cantidad de reserva de memoria y CPU configurada en la máquina con mayores reservas del Clúster. Este tipo de control de admisión comprueba que la suma de los recursos de memoria y CPU de todos los

8 Hosts del Clúster menos la de los Hosts que queramos soportar en Failover, serán capaces de asumir el producto de los recursos definidos en el Slot Size por el número de máquinas virtuales existentes. Es un calculo un tanto complicado. Para mayor detalle y ejemplos se puede consultar esta web: Percentage of Cluster Resources Reserved Admission Control Policy: Asegura la capacidad de Failover realizando reservas de un porcentaje especifico de los recursos de CPU y Memoria de todos los Hosts que forman el Clúster Specify Failover Hosts Admission Control Policy: Asegura la capacidad de Failover reservando una cantidad de Hosts que puedan asumir las máquinas virtuales de los Hosts fallidos. Cuando un Host falla, HA intenta reiniciar sus máquinas virtuales en uno de los Hosts especificados para el Failover.

9 Funciones y requisitos de DRS Vmware Vsphere DRS proporciona balanceo de carga entre los recursos de CPU y memoria de todos los Hosts de manera que las máquinas virtuales se distribuyan de manera equitativa entre los Hosts del Clúster en función de sus requerimientos. Vmware Vsphere DRS monitorizará continuamente los Hosts y máquinas virtuales asegurando que se cumplan las reservas de las máquinas virtuales y que los Hosts tengan suficientes recursos para satisfacerlos. En caso de falta de recursos, DRS nos avisará o realizara una migración de Host de las máquinas virtuales a través de Vmotion en función del nivel de automatización que le hayamos configurado. Se pueden configurar 3 niveles de automatización: Manual: DRS no realiza ninguna migración de ninguna máquina virtual, pero te recomienda cuales se deberían realizar Partially automated: DRS nos recomendará cuales son las migraciones que se deberían realizar y nos realizará migraciones de las máquinas virtuales tan solo cuando un Host del Cluster se encienda. Fully automated: DRS migrará automáticamente las máquinas virtuales en función de la necesidad de recursos y disponibilidad de estos en los Hosts. En el caso de la configuración Fully automated, podremos configurar un umbral de sensibilidad a la hora de realizar las migraciones que van entre: Conservative: Es la configuración de sensibilidad más baja. Sólo migrará máquinas virtuales para satisfacer reglas de afinidad, o en el caso de que un Host entre en modo mantenimiento Aggresive: Es la configuración de sensibilidad más alta. Migrará cualquier máquina de Host a la que detecte que se puede producir una mejor en la asignación de recursos. A través de DRS podremos asignar reglas de afinidad y antiafinidad de manera que podremos forzar las máquinas a que corran únicamente en un Host o grupo de Host, o que jamás corran en un Host o grupo de Hosts. DRS utiliza Vmotion para realizar las migraciones de las máquinas virtuales. Para realizar los Vmotion correctamente y por tanto poder utilizar DRS se necesitan ciertos requisitos: Storage compartido: Para poder realizar Vmotion de las máquinas virtuales se requieren que los Hosts tengan acceso a los mismos Datastores SAN o NAS Compatibilidad de Procesadores: Vmotion requiere que los Hosts que van a realizar la migración de una máquina virtual tengan el mismo tipo de procesador (Intel vs AMD) y que estos sean de la misma familia. Para asegurar la compatibilidad en este punto se puede configurar EVC, que trataremos en la próxima sección. Configuración de red: Deberemos tener habilitado un switch con un puerto Vmkernel con la opción de Vmotion activada y la red deberá correr a Gigabit para funcionar adecuadamente.

10 Funciones y requisitos de DPM vsphere Distributed Power Management (DPM) permite a un Clúster configurado con DRS reducir su consumo eléctrico a través del apagado y encendido de los Hosts del Cluster según el uso de sus recursos. DPM migrará las máquinas cuando su necesidad de recursos es más bajo a un número límitado de Hosts de manera que pueda dejar en Standby los Hosts liberados, produciendo así un menor consumo eléctrico. DPM arrancará los Hosts automáticamente y migrará a ellos las máquinas virtuales cuando estás empiecen de nuevo a requerir recursos. vsphere DPM puede utilizar los siguientes protocolos de control de energía para dejar los Hosts en modo Standby: Intelligent Platform Management Interface (IPMI) Hewlett-Packard Integrated Lights-Out (ilo) Wake-On- LAN (WOL) Cada uno de estos protocolos debe estar soportado por el hardware de los Hosts para ser configurado. Si un Host no sporta ninguno de estos tres métodos no podrá ser configurado para utilizar DPM. Si un Host soporta varios protocolos de control de energía deberemos decantarnos por utilizarlo según el siguiente orden IPMI, ilo, WOL. Cada uno de los anteriores métodos se configura según las indicaciones de hardware del Host. En el siguiente link se detalla la configuración a realizar según el tipo: 50/index.jsp?topic=/com.vmware.vsphere.resmgmt.doc_50/GUID-98BD5A8A-260A-494F- BAAE-74781F5C4B87.html Podremos configurar DPM con los siguiente niveles de automatización: Off: DPM está desactivado y no realizará migraciones, ni recomendaciones. Manual: No se realizará el encendido o apagado de los Hosts, ni las migraciones de las máquinas virtuales automáticamente. DPM igualmente nos recomendará que migraciones de máquinas virtuales deberíamos realizar y que hosts deberíamos apagar o encender. Estas recomendaciones aparecerán el la pestaña del Clúster DRS dentro de nuestro Vsphere Client Automatic: Se realizarán las migraciones de las máquinas virtuales y el apagado de los Hosts automáticamente. En el caso de la configuración Automatic podremos configurar un umbral de sensibilidad a la hora de realizar las migraciones y el apagado de los Hosts según el grado de sensibilidad que va desde: Conservative: Es la configuración de sensibilidad más baja. Sólo encenderá Hosts y migrará máquinas virtuales para satisfacer la configuración de HA o para cumplir las reservas de las máquinas virtuales o pools de recursos. Aggresive: Es la configuración de sensibilidad más alta. Encenderá y apagará los Hosts y Migrará cualquier máquina virtual en cuanto detecte que se puede producir una mejora en la asignación de recursos, o una reducción del consumo eléctrico sin violar las reservas de las máquinas virtuales, pools de recursos o configuración del control de admisión de HA Para configurar DPM necesitaremos cumplir también los requisitos detallados en la configuración de DRS y Vmotion.

11 Funciones y requisitos de EVC EVC mejora la compatibilidad a la hora de realizar las migraciones de máquinas virtuales vmotion en un Clúster. Después que EVC es habilitado para un Clúster, todos los hosts en ese Clúster son configurados para presentar características idénticas de CPU y asegurar la compatibilidad de las CPUs con vmotion. Las propiedades presentadas para cada host son determinadas seleccionando una configuración base predefinida de EVC, según tipo de procesador y familia. VirtualCenter no permitirá la incorporación de nuevos Hosts que no puedan ser configurados automáticamente para ser compatibles con la configuración base seleccionada de EVC. Antes de crear un Clúster EVC se debe asegurar que todos los host que se van a añadir al Clúster cumplen los requerimientos listados en la sección de Requerimientos de EVC.

12 Funciones y requisitos de FT Vsphere FT ofrece disponibilidad continua de las máquinas virtuales mediante la creación de una máquina virtual secundaria que es idéntica a la principal, y realiza las mismas acciones que la principal pero funcionando sobre un Host diferente. Permitiendo así la continuidad de los servicios de la máquina virtual en caso de Failover de alguno de estos Hosts. La máquina primaria y secundaria intercambian Hearbeats. Este intercambio permite a la máquinas virtuales conocer en todo momento el status de la otra máquina. En cuanto se produce un Failover en el Host corriendo la máquina virtual primaria, la máquina secundaria pasa a tener el control, reemplazando así la máquina primaria. Una nueva máquina secundaria será creada en un Host diferente. En el caso de que el Failover se produjera en el Host que controla la máquina secundaria, una nueva máquina secundaria sería creada automáticamente en cualquier otro Host con recursos suficientes. La idea es que la máquina primaria siempre tenga una réplica funcionando en un Host diferente evitando la interrupción del servicio de la máquina virtual o la pérdida de datos. A las máquinas virtuales primaria y secundaria funcionando bajo Fault Tolerance se les aplicará una regla de antiafinidad, de manera que jamás sean funcionando bajo el mismo Host. Ni bajo una migración automática de Fault Tolerance, ni bajo una migración de Vmotion. Utilizaremos Fault Tolerance en cualquier máquina virtual que necesite tener una disponibilidad absoluta por ser crítica, y que no pueda ser duplicada bajo un software de clusterización propio. Por ejemplo bajo Microsoft Cluster Server en el caso de ser un producto de Microsoft. Fault Tolerance es bastante restrictivo y requiere de bastantes requisitos para funcionar correctamente: Los Hosts ESX/ESXI que correrán las máquinas en FT deben ser de la misma versión Los Hosts ESX/ESXI que correrán las máquinas en FT deben estar conectados a los mismos Datastores y Networks Se debe haber configurado un Vmkernel con capacidad de FT Logging y Vmotion. FT sólo correrá en máquinas corriendo bajo un Clúster con HA Los procesadores de los Hosts q en los que correrán las máquinas en FT deben ser de la misma familia y tipo. Los Hosts ESX/ESXI que correrán las máquinas en FT deben tener la capacidad de virtualización de hardware activada en la bios (Intel-VT o AMD-V) No se puede activar el FT en máquinas que tengan dispositivos conectados (por ejemplo un CD) Los discos de las máquinas virtuales en FT deben ser del tipo Thick (si son del tipo Thin, nos obligará a transformarlos a tipo Thick) Solamente podremos utilizar FT en máquinas virtuales con un sólo VCPU configurado (esta es el requerimiento más importante y que limita más la tecnología) Sólo se soportan los siguientes Sistemas Operativos y los siguientes tipos de CPU's en los Hosts que correrán las máquinas en FT: No podremos realizar FT sobre una máquina que tenga Snapshots, ni podremos realizar snapshots posteriores. No podremos realizar Vmotion Vstorage en alguna de las máquinas con FT

13 En el siguiente video podremos ver el proceso de creación de un Cluster limpio, sin la configuración de ninguno de sus servicios asociados, y veremos cúal es el procedimiento para modificar posteriormente el Clúster, sacar los Hosts del Clúster y suprimir el Clúster.

14 3.2. Configuración y propiedades del HA Para configurar HA debemos crear un Clúster y habilitar en él el servicio de HA. En el siguiente video se detallan los procesos para realizar la creación de un Clúster con HA habilitado. Recorreremos las diferentes opciones de configuración de manera que especificaremos cúal será su comportamiento en el caso que se produzca un Failover o un Network Isolated sobre un Host.

15 3.3. Configuración y propiedades del DRS Podemos configurar un Clúster para que reparta su carga de trabajo entre los diferentes Hosts que componen un Clúster. En el siguiente video veremos como crear un Clúster con el servicio de DRS e integrar los Hosts en él. Detallaremos cada uno de los parámetros de configuración, su grado de automatización y la sensibilidad de su comportamiento.

16 3.4. Configuración y propiedades del DPM En el siguiente video veremos la configuración del servicio DPM sobre un Clúster DRS. En el video crearemos un clúster, habilitaremos DRS con las opciones por defecto y nos centraremos en la configuración, automatización y umbral de sensibilidad del servicio DRS. Por otro lado veremos cómo se debe configurar un Host para que Vcenter pueda realizar el encendido o puesta en StandBye del mismo.

17 3.5. Configuración y propiedades del EVC Podemos configurar un Clúster con una baseline por tipo y familia de procesador, de manera que en un proceso de escalabilidad no podamos agregar Hosts de una familia y tipo de procesador diferentes a los definidos en la baseline, y así asegurarnos la compatibilidad a la hora de realizar las migraciones Vmotion. En el siguiente video veremos la creación de un Clúster con el servicio de EVC habilitado. Configuraremos una baseline por familia y tipo de procesador e incluiremos los Hosts en el Clúster.

18 3.6. Configuración y propiedades del FT Podemos configurar el servicio de Fault Tolerance en un entorno de Clúster con el servicio de HA habilitado. En el siguiente video veremos como habilitar el servicio de FT sobre una máquina contenida en un Clúster. Comprobaremos los requisitos para la activación del servicio y veremos la correcta creación de la máquina secundaria sobre otro Host en modo de antiafinidad con la primaria.

19 Tratamiento de los pools en un Cluster de Vmware Vsphere Cuando realizamos un Clúster con cualquier tipo de configuración e incluimos en él a Hosts que contienen máquinas virtuales siempre se nos respetará la configuración de Shares, Límites y Reservas de las máquinas virtuales de manera individual, es decir tal y como las hemos configurado en la pestaña de recursos de la máquina virtual: El comportamiento difiere en cuanto las Reservas, Límites y Shares son realizados mediante grupos de reservas a través de los Pools. Debemos diferenciar dos tipos de comportamiento en cuanto intentemos agregar las máquinas virtuales al pool de recursos, en función de que tengamos habilitado o no, el servicio de DRS. Servicio de DRS no habilitado: Los Pools de recursos existentes en el Host que va a ser agregado al Clúster serán borrados y deberemos crearlos de nuevo en el Clúster. Los Pools de recursos no podrán ser creados directamente en un Host, si esté pertenece a un Clúster. Servicio DRS habilitado: Al añadir un Host al Clúster, Vmware Vcenter nos preguntará si deseamos agregar los pools existentes en el Clúster o si deseamos eliminarlos.

20 En el caso que deseemos agregar los Pools de recursos del Host en el Clúster. Los Pools existentes en el Host serán creados como hijos de un nuevo Pool, preservando así la configuración de Pools del Host recién añadido en el Clúster.

21 Almacenamiento de archivos swap en los Clusters Cada vez que se enciende una máquina virtual se crea un archivo de Swap igual a la memoria virtual configurada de la máquina virtual menos la reserva de memoria que le hayamos configurado. En el caso de tener una reserva de memoria igual a la memoria configurada de la máquina virtual, no se creará archivo de Swap. Este archivo de Swap es utilizado en caso de quedarnos sin memoria disponible en el Host para las máquinas virtuales, provocando así una pérdida considerable de rendimiento. Es posible configurar los Hosts de manera que podamos guardar el Swap de las máquinas virtuales que contiene en un diferente Datastore que el que utiliza el resto de archivos de configuración de las máquinas virtuales. Esté procedimiento, aunque no es habitual, se puede realizar para liberar el espacio de un Datastore saturado, o para mejorar el rendimiento de la máquina virtual, ya que las lecturas y escrituras del Swap de la máquina se realizaran un diferente Datastore. Se debe tener en cuenta que tener el archivo Swap de una máquina virtual almacenado en un diferente Datastore nos puede ocasionar problemas y perdida de rendimiento a la hora de realizar migraciones Vmotion: En algunas ocasiones los Hosts deberán copiar el Swap de un Datastore a otro para poder realizar el Vmotion de la máquina virtual. Realizaremos la configuración del almacenamiento del Swap de las máquinas virtuales en una localización diferente a la del resto de archivos de configuración, a través de la opción Virtual Machine Swapfile Location, dentro de la pestaña de Configuración del Host: Cuando creamos un Clúster por defecto nos elimina la configuración anteriormente realizada por los Hosts sobre la diferente localización para el archivo de Swap. Podemos mantener dicha configuración si elegimos la opción de mantener la configuración de Swap, en la pestaña de Swapfile Location del Clúster:

22 2 de 2 07/07/2013 1:14

23 Parámetros avanzados para resolución de conflictos Reconfigurar HA En ciertas ocasiones podemos perder la configuración del HA en un Host de un Clúster. Para reconfigurar HA sin tener que volver a incorporarse en el Clúster, podemos hacer un Reconfigure HA: Solucionar advertencias de un Cluster Una advertencia típica que nos mostrará Vcenter tras la creación de un Cluster es la de This host currently has no management network redundancy. Para solventarla tenemos que añadir una tarjeta de red en el switch que tenga asignado el puerto VMkernel con el Management Traffic habilitado: Otra advertencia típica tras la creación de un Cluster es la de The number o vsphere HA heartbeat datastores for this host is 1, wich is less tan required:2 :

24 Por defecto un Clúster con HA habilitado debe ser configurado con dos Datastore hábiles para comprobar la integridad de los Hosts a través de Heartbeats. Debemos configurar esos dos Datastores mínimos en la configuración del Clúster: Y configurarlos para que sean accesibles en los Hosts: Asegurar la prioridad de reinicio de las máquinas virtuales: Es importante dar la prioridad de reinicio necesaria a las máquinas virtuales en función de su dependencia con el resto de las máquinas. Por ejemplo las máquinas que proveen servicios a otras máquinas (DNS, Active Directory, SQL SERVER, Proxy, etc.) debe ser configuradas con una prioridad de reinicio más alta que el resto de máquinas:

25 Cambiar las opciones avanzadas de los servicios de HA y DRS Es posible añadir opciones avanzadas en el servicio de DRS o de HA: Modificar estas opciones es peligroso pues puede afectar el comportamiento del servicio. De todas

26 maneras algunos ejemplos que eliminan las advertencias comentadas anteriormente: das.ignoreinsufficienthbdatastore: Elimina la comprobación de un mínmo de 2 DataStores accesibles por Host para los Heartbeates, en la configuración de HA (True o False) das.heartbeatdsperhost: Cambia el número mínmo de Datastores accesibles mínimos de DataStores accesibles por Host para los Heartbeates, en la configuración de HA (2 a 5) das.ignoreredundantnetwarning: Elimina la comprobación de redundancia de tarjetas de red en el management traffic de los Hosts dentro de un Cluster (True o False)