En los próximos meses buscaremos agregar conmutación por error y equilibrio de carga a nuestro entorno. Tendremos 2 servidores que son Hyper V Hosts. Buscamos tener un servidor de aplicaciones IIS y un servidor de base de datos SQL en ambos hosts. De esta manera, si una caja falla, la otra estará allí para ocupar su lugar. Ahora mi confusión proviene de algunas búsquedas en Google que he estado haciendo. Por lo que puedo decir, parece haber agrupación SQL/configuración de transacciones de igual a igual, así como agrupación en clústeres Hyper-V. No estoy seguro de qué funcionaría mejor en esta situación. Los hosts también tendrán otros servidores aleatorios, como el centro del sistema, nuestro servidor de tickets, el servidor de administración de Exchange y varios otros divididos entre los dos. Así que no estoy seguro de si ahora el clúster Hyper-V será la peor opción.
Gracias.
Respuesta1
Con la agrupación en clústeres de Hyper-V, tiene un grupo de servidores Hyper-V (2+), todos conectados al mismo conjunto de almacenamiento de red, de modo que los LUN están disponibles para todos los servidores en el clúster de Hyper-V. Debe tener almacenamiento de red para esta configuración. Con Hyper-V Live Migration, puede mover una máquina virtual en ejecución de un host Hyper-V a otro. Esto permite que la carga de trabajo de un servidor pase a otro si el servidor falla. Esto le brinda redundancia física si los servidores restantes son capaces de manejar la carga de las máquinas virtuales adicionales. Esta configuración no lo protege de la corrupción del sistema operativo y las aplicaciones de la máquina virtual. (Verhttp://technet.microsoft.com/en-us/library/dd446679(WS.10).aspxpara obtener detalles sobre esta configuración).
SQL tiene su propia redundancia disponible con varias opciones de agrupación en clústeres diferentes. Puede realizar una agrupación tradicional activa/pasiva, con un nodo activo y uno o más nodos pasivos. Esta configuración requiere un disco compartido entre los servidores y solo se monta en el nodo activo. SQL también admite varios tipos de replicación, lo que permite múltiples nodos activos. Este método no requiere almacenamiento compartido y mantiene una copia separada de la base de datos en cada servidor. (Verhttp://msdn.microsoft.com/en-us/library/ee523927(v=sql.100).aspxpara opciones de alta disponibilidad de SQL 2008)
La agrupación en clústeres a nivel de SQL protege contra un sistema operativo o una aplicación fallidos en un nodo individual, lo que permite la conmutación por error automática en ese escenario. Si cada instancia está en un servidor Hyper-V diferente, también estará protegido contra fallas de hardware. Además, algunos de los métodos de agrupación en clústeres para el servidor SQL protegen contra la corrupción de la base de datos en nodos individuales. El uso de un clúster Hyper-V y una sola instancia del servidor SQL no lo protege contra fallas del sistema operativo o del software en la máquina virtual. Si el tiempo de inactividad no es un gran problema, puede restaurar desde una instantánea de VM en un corto período de tiempo.
Editar: Olvidé la parte de equilibrio de carga de IIS.
Para equilibrar la carga de IIS, puede utilizar el equilibrio de carga de red de Windows, que crea una IP virtual que se comparte entre ambos hosts. (Verhttp://technet.microsoft.com/en-us/library/cc770689(v=ws.10).aspx)
Se aplican las mismas reglas con el servidor IIS que con el servidor SQL para determinar si la agrupación en clústeres Hyper-V o NLB es la opción correcta. Además, para sus otras máquinas virtuales, a menos que también estén agrupadas en clústeres o con carga equilibrada, no están protegidas contra un problema con el host Hyper-V sin agrupación en clústeres de Hyper-V.
Respuesta2
Si va a reflejar invitados virtuales entre dos hosts, evite la agrupación en clústeres de HyperV. Eso permite que los invitados virtuales se inicien en otro host cuando uno falla y le permite equilibrar las cargas a nivel de host.
Si está realizando una agrupación en clústeres de SQL, puede realizar el paso de respaldo de SQL mucho más rápido y comenzar a manejar las solicitudes. Y para el equilibrio de carga web, utilice NLB (involucre a su encargado de la red para hacerlo bien, lea sobre NLB de multidifusión). Y utilice la agrupación en clústeres de Exchange entre dos virtuales de Exchange. Serás mucho más feliz.