Windows Server 2008 R2: Red en los clústeres de conmutación por error
Error no es una opción, configuración de clústeres de conmutación por error en Windows Server puede ayudar a asegurar una alta disponibilidad.
John marlines
El modelo de red en Windows Server 2008 y Windows Server 2008 R2 Failover Clustering proporciona más robusta y fiable comunicación entre todos los nodos del clúster, lo que aumenta considerablemente la eficiencia y la fiabilidad de la organización por clústeres de conmutación por error. Hay también varias características nuevas, incluyendo:
- Comunicación más confiable mediante unidifusión TCP y UDP
- Compatibilidad con IPv6
- Soporte para localizar los nodos del clúster en subredes enrutadas independientes
- Control más específico sobre detección de fallos de red
Deberá utilizar hardware de red marcado como "Certificado para Windows Server 2008". Cualquier otro componente de la solución de clúster de conmutación por error también deberá ser certificada del mismo modo. Si se usa iSCSI, los adaptadores de red necesitan estar dedicado para cualquier comunicación de red o iSCSI, no ambos.
Al diseñar la infraestructura de red para conectar los nodos del clúster, es esencial para evitar puntos únicos de falla. Hay muchas formas para hacer esto. Puede conectar los nodos del clúster con varias redes distintas. También se puede conectar los nodos del clúster con una red construida con adaptadores de red combinados, conmutadores redundantes, enrutadores redundantes o hardware similar eliminar puntos únicos de falla. Estos requisitos arquitectónicos difieren de los clústeres de servidores en Windows Server 2003, que requiere dos redes distintas.
Comunicaciones de clúster
Windows Server 2008 Failover Clustering, ahora se utiliza un adaptador de red virtual denominado adaptador Virtual de clúster de conmutación por error de Microsoft para la comunicación entre nodos del clúster. También verá esto en el Administrador de dispositivos en adaptadores de red (seleccione Mostrar dispositivos ocultos). También verá, al emitir el comando IPCONFIG /ALL. Este adaptador de red controla todo el enrutamiento de paquetes a través de las redes adecuadas para la comunicación, une y así sucesivamente.
Este adaptador tendrá un dirección APIPA definido en el 169.254.0.0/16 de bloque de dirección. En IPv6, que están asignados por el fe80:: / 10 del prefijo. En algunos entornos, cuando los adaptadores tienen una dirección APIPA, los adaptadores están deshabilitados. Si deshabilita al adaptador del clúster Virtual, podrá desactivar la comunicación entre los nodos.
El objetivo es mantener la conectividad TCP/IP entre dos o más sistemas, a pesar del fracaso de cualquier componente en la ruta de acceso de red. Por lo que tiene que haber una ruta de acceso física alternativo. En otras palabras, una falla de componentes de red (si es una NIC, enrutador, conmutador o concentrador) no debería causar una ruptura de comunicación.
Debe continuar la comunicación de manera oportuna. Puede haber una respuesta más lenta, pero comunicación se mantendrá siempre que hay una ruta física alternativa o vínculo. Realmente este entra en juego cuando se habla con nodos en sitios independientes o subredes.
Otro cambio en Windows Server 2008 Failover Clustering es el mecanismo de latido de clúster. Mientras sigue utilizando el puerto 3343, ha pasado de un mecanismo de comprobación del estado de difusión de UDP a una comunicación de unidifusión UDP. Es similar a un comando ping en que utiliza un proceso de solicitud y respuesta, pero incluye características más sofisticadas, como seguridad y la secuencia de numeración.
También ha cambiado el comportamiento predeterminado en términos de cuántas respuestas son necesarios antes de que el nodo se considera inalcanzable, iniciando una reagrupación para obtener una nueva vista de la pertenencia al clúster. Los latidos de clúster comunicarle todos los nodos que es hacia arriba y abajo. De forma predeterminada, la configuración de esta se controla mediante:
- SameSubnetDelay: frecuencia de latidos para los nodos de la misma subred
- SameSubnetThreshold: umbral de las demoras para los nodos de la misma subred
- CrossSubnetDelay: frecuencia de latidos para los nodos de diferentes subredes
- CrossSubnetThreshold: umbral de las demoras para los nodos de diferentes subredes
Esta configuración y el método para modificarlos, se definen en los "Configurar latido y DNS configuración en un múltiples sitios Failover Clusters" página de la biblioteca de TechNet. Hay un "latido" enviado a través de con un número de secuencia, decir del Nodo1 al nodo2. El nodo 2 responde con el mismo número de secuencia. El nodo 1 vuelve a enviar el mismo número de secuencia al nodo2 y Nodo2 devuelve una última vez.
Node1, a continuación, sería determinar esta secuencia de latido completa e iniciar el proceso de nuevo con otro número de secuencia. Si cualquiera de las secuencias de latidos son descartado o no recibido, se considera un latido "perdido". De forma predeterminada, si se pierden cinco de estas secuencias, el nodo se considera hacia abajo o inactivo.
Puede cambiar esta configuración para aumentar el retardo o el umbral, pero sólo puede solucionar los problemas de red. Si hay algún problema de latencia de red, esto se puede obtener a su alrededor, pero no solucionaría nada. Por lo que se tenga en cuenta que al efectuar cambios en la configuración de retraso o umbral no se considera una técnica para solucionar problemas.
Los latidos del corazón, de forma predeterminada, se van a utilizar IPv6, ya que es un protocolo más rápido que IPv4. Si se ha deshabilitado la IPv6, en su lugar utilizará IPv4. Un clúster de conmutación por error no mezclar y coincidir con IPv6 e IPv4. Utilizará uno o el otro, pero no ambos al mismo tiempo.
Creación de clústeres
Cuando se crea un clúster en Windows Server 2008 y Windows Server 2008 R2, el controlador de red del clúster detecta y crea las redes en función de si es una puerta de enlace predeterminada en el adaptador. Si detecta una puerta de enlace predeterminada, se establece esa red para permitir a los clientes para conectarse y utilizarla para las comunicaciones de clúster.
Esto permite que las direcciones IP de clúster y puntos de acceso de cliente (nombres de red) utilizan la red. También ofrece es un valor de métrica comenzando por 10.000. Si una red no tiene una puerta de enlace predeterminada, se le dará un valor de métrica empezando por 1.000. A continuación, sólo se seleccionará para las comunicaciones de clúster. Cada red detecta aumenta el métrico incremento por 100.
Una cosa acerca de cómo funciona ahora es que no hay ningún concepto más de una red "privada" y "public". Por lo tanto, el antiguo "recomienda 'Private Heartbeat' Configuration on a Cluster Server" artículo para Windows Server 2003 clustering no es válido. Las comunicaciones de clúster todavía se van a pasar a través de todas las redes.
En versiones anteriores, ha definido la red que desea utilizar para las comunicaciones de clúster. Siempre y cuando dicha red estaba disponible, el clúster usaría sólo en esa red. Windows Server 2008 y Windows Server 2008 R2 utilizan todas las redes. Si hay un problema con una red, cambiará automáticamente entre redes.
Hay una métrica interna que utiliza el controlador de red del clúster. No utilice el valor de métrica general de TCPIP. Puede ver los valores de métricos con el siguiente comando Windows PowerShell:
Get-ClusterNetwork | Nombre de FT, métrica
Los valores de métricos realmente entran en juego cuando se habla de tener un clúster con altamente disponibles máquinas virtuales (VMs) y el uso de volúmenes compartidos de clúster.
Por ejemplo, supongamos que desea ejecutar este comando con estas redes configuradas:
Nombre -------------------------------------------------- Red iSCSI |
Métrica -------------------------- 1000 |
Cuando se usa volúmenes compartidos de clúster, utilizará la red de valor de métrica más baja para el tráfico CSV o redirige el acceso de modo. Al utilizar la característica de migración en vivo del clúster de conmutación, utilizará la métrica más baja para el segundo.
En el ejemplo, el tráfico CSV pasará a través de la red iSCSI y migraciones activas pasará a través de la red utilizada para las copias de seguridad. Al tomar una copia de seguridad de las máquinas virtuales, los volúmenes compartidos de clúster tendrán un acceso en modo redirigida. Esto va a interferir con las conexiones ISCSI y podría conducir a errores de disco. Una copia de seguridad de datos en la unidad local del nodo 1 y una migración en vivo pueden interferir entre sí.
Debe volver a configurar las redes para obtener todo lo que necesita. Para la red de la migración en vivo, puede cambiarlo por el que se muestre las propiedades de una de las máquinas virtuales. En la ficha de la migración en vivo, cambie a la red de clúster de LM. Para ello, sólo debe hacerlo en una única VM porque se trata de una configuración global para todas las máquinas virtuales.
Para la red CSV, sólo puede afectar a este cambio a través de Windows PowerShell. Para solicitar las redes de baja a alta, utilice los comandos siguientes:
Get-ClusterNetwork "CSV Cluster" | %{$_.Metric=800} Get-ClusterNetwork "LM Cluster" | %{$_.Metric=900} Get-ClusterNetwork "Backup Network" | %{$_.Metric=1000} Get-ClusterNetwork "ISCSI Storage Network" | %{$_.Metric=1100}
Ejecutar el comando para ver las métricas mostrará ahora:
Nombre -------------------------------------------------- Red iSCSI |
Métrica ------------------------ 1100 |
La red de clústeres CSV se establece para la métrica de 800. Adición de cualquier nueva red que no tenga una puerta de enlace predeterminada sería más alta. Ahora con métricas configuradas correctamente, puede realizar copias de seguridad o live migrar VMs sin los conflictos en las redes.
Lo último para mencionar es la validación de clúster. Puede ejecutar algunas pruebas de validación de red para determinar los problemas de conectividad, las configuraciones de red y así sucesivamente. Puede ejecutar estas pruebas en cualquier momento sin afectar la producción.
Las pruebas de validación de clúster incluyen:
- Configuración del clúster
- Información de red del clúster de lista
- Red
- Lista orden de enlace de red
- Validar la configuración de red del clúster
- Validar la configuración de IP
- Validar varias propiedades de subred
- Validar la comunicación de red
Puede encontrar los detalles de las pruebas de validación de clúster en el "Descripción de las pruebas de validación de clúster" página de TechNet Library. Esto le mostrará exactamente lo que buscan las pruebas y no de lo que cada prueba.
.jpg)
**John marlines**es un ingeniero de soporte técnico senior en el grupo de apoyo técnico comercial. Ha colaborado con Microsoft durante más de 19 años, con los últimos 14 años, centrándose en los servidores de clúster.