Go to main content
Guía de administración de Oracle® ZFS Storage Appliance, versión OS8.7.0

Salir de la Vista de impresión

Actualización: Marzo de 2017
 
 

E/S de interconexión del cluster

Todas las comunicaciones entre los controladores constan de uno o varios mensajes transmitidos por uno de los tres enlaces de E/S del cluster proporcionados por el hardware CLUSTRON (consulte Controller Cluster I/O Ports in Oracle ZFS Storage Appliance Cabling Guide). Este dispositivo ofrece dos enlaces serie de baja velocidad y un enlace Ethernet. El uso de los enlaces serie ofrece una mayor fiabilidad, ya que puede suceder que los enlaces Ethernet no reciban servicio con rapidez suficiente cuando el sistema está bajo condiciones de carga extrema. La falsa detección de fallos y la toma de control no deseada son las peores maneras en las que un sistema en cluster puede responder a la carga. Durante la toma de control, no se responderán las solicitudes, sino que quedarán en la cola de los clientes, lo que genera una avalancha de solicitudes demoradas después de la toma de control que se suman a la carga ya intensa. Los enlaces serie utilizados por los dispositivos Oracle ZFS Storage Appliance no son susceptibles a este modo de error. El enlace Ethernet proporciona un transporte de mayor rendimiento para los mensajes sin latido, como la sincronización para volver a unirse, y proporciona un latido de respaldo.

Los tres enlaces se forman con cables EIA/TIA-568B (8 cables, Gigabit Ethernet) rectos comunes. Para poder utilizar cables rectos entre dos controladores idénticos, los cables se deben utilizar para conectar sockets opuestos de los dos conectores, como se muestra en Conexión de cables de cluster en la Guía de cableado de Oracle ZFS Storage Appliance.

Los controladores en clusters únicamente se comunican entre sí mediante una red privada segura establecida por las interconexiones del cluster y nunca mediante interfaces de red previstas para servicio o administración. El mensaje pertenecerá a una de dos categorías generales: los latidos regulares utilizados para detectar el fallo de un controlador remoto y el tráfico de nivel superior asociado con el gestor de recursos y el subsistema de gestión del cluster. Los latidos se envían, y se esperan, en los tres enlaces. Se transmiten de manera continua a intervalos fijos y nunca se confirma su recepción ni se retransmiten, ya que todos los latidos son idénticos y no contienen información exclusiva. Por cualquiera de los enlaces, se puede enviar otro tipo de tráfico; normalmente se utiliza el enlace que esté disponible más rápido en el momento de la transmisión. La recepción de este tráfico se confirma, el tráfico se verifica y se lo retransmite según sea necesario para mantener un transporte confiable para el software de nivel superior.

Independientemente de su tipo u origen, cada mensaje se envía como un único paquete de 128 bytes y contiene una carga útil de datos de 1 a 68 bytes y un número hash de verificación de 20 bytes para asegurar la integridad de los datos. Los enlaces serie funcionan a 115200 bps con 9 bits de datos y un único bit de inicio y fin; el enlace Ethernet funciona a 1 Gbps. Por lo tanto, la latencia de mensaje efectiva en los enlaces serie es de aproximadamente 12,2 ms. La latencia de Ethernet varía mucho. Si bien las latencias típicas son del orden de los microsegundos, las latencias efectivas para el software de gestión del dispositivo pueden ser mucho mayores debido a la carga del sistema.

Normalmente, cada uno de los controladores envía mensajes de latidos por los tres enlaces de E/S del cluster a intervalos de 50 ms. Si no se recibe ningún mensaje después de 200 ms (enlaces serie) o 500 ms (enlaces Ethernet), se considera que el enlace presentó un fallo. Si se produce un fallo en los tres enlaces, se supone que el fallo es del par y se realiza el arbitraje de la toma de control. En el caso de un aviso grave, el controlador que falla transmite un único mensaje de notificación por cada uno de los enlaces serie, y el par inicia la toma de control de inmediato, independientemente del estado de los demás enlaces. Dadas estas características, el subsistema de agrupación en clusters normalmente puede detectar que el par ha fallado dentro de un período de:

  • 550 ms si el par dejó de responder o se apagó.

  • 30 ms si el par encontró un error fatal de software que generó un aviso grave del sistema operativo.

Todos los valores descritos en esta sección son fijos; el dispositivo Oracle ZFS Storage Appliance no ofrece la capacidad de ajustar estos parámetros (ni tampoco hay necesidad de hacerlo). Se consideran como detalles de implementación y se los incluye aquí solo con fines informativos. Se pueden cambiar sin aviso en cualquier momento.


Notas -  Para evitar daños en los datos tras la reubicación física de un cluster, verifique que todo el cableado del cluster esté correctamente instalado en la nueva ubicación. Para obtener más información, consulte Prevención de situaciones de cerebro dividido.

Temas relacionados