¿Qué es SCSI-3? ¿A qué nos referimos cuando hablamos de Reservas Persistentes?

¡Hola!

Hoy me apetece hablar de algo que seguro nos habéis oído a muchos de nosotros cuando habéis sufrido algún problema de discos en un cluster y es eso de las “Reservas Persistentes de SCSI-3”.

Lo primero de todo es saber qué es eso de SCSI-3… Como siempre en estos casos y, aunque hay que utilizarla con cuidado, la Wikipedia nos viene muy bien:

https://es.wikipedia.org/wiki/SCSI

SCSI , acrónimo inglés de Small Computers System Interface (Sistema de Interfaz para Pequeñas Computadoras), es una interfaz estándar para la transferencia de datos entre distintos dispositivos del bus de la computadora . Algunos profesionales lo castellanizan como escasi, por la pronunciación en inglés de su sigla , otros por el contrario prefieren deletrearlo.

Para montar un dispositivo SCSI en un ordenador es necesario que tanto el dispositivo como la placa madre dispongan de un controlador SCSI. Es habitual que el dispositivo venga con un controlador de este tipo, pero no siempre es así, sobre todo en los primeros dispositivos. Se utiliza habitualmente en los discos duros y los dispositivos de almacenamiento sobre cintas, pero también interconecta una amplia gama de dispositivos, incluyendo escáneres , unidades CD-ROM , grabadoras de CD , y unidades DVD . De hecho, el estándar SCSI entero promueve la independencia de dispositivos, lo que significa que teóricamente cualquier cosa puede ser hecha SCSI (incluso existen impresoras que utilizan SCSI).

¿Y qué significa el 3?

Como hemos visto, SCSI es un estándar. Dicho estándar está mantenido por un comité técnico responsable de la definición de la arquitectura SCSI (cómo deben conectarse los dispositivos SCSI, qué señales deben enviar, qué funciones implementar, etc) llamado T10.

https://www.t10.org/index.html

Dicho comité decidió que se debía ampliar la funcionalidad de la arquitectura SCSI que existía entonces, y se pasó a ampliar SCSI a la tercera generación, es decir, SCSI-3.

Windows Server 2008 está diseñado para utilizar únicamente comandos y especificaciones SCSI-3 y exactamente eso son las reservas persistentes.

Las reservas se utilizan para que un dispositivo SCSI sea capaz de procesar comandos de un set específico de lo que se llama I_T Nexus (combinación de puertos iniciadores accediendo puertos destino, Initiators-Targets) y rechazar cualquier comando proveniente de otro I_T Nexus diferente.

Asimismo, el mecanismo de las reservas persistentes permite que se preserven dichas reservas incluso ante fallos de los dispositivos Iniciadores SCSI como un hard reset, reset lógico o pérdida del par Initiator-Target. Aun así, una reserva persistente de un I_T Nexus que esté fallando puede ser confiscada por otro I_T Nexus como parte del proceso de recuperación ante fallos.

Por tanto las reservas persistentes se mantendrán hasta que se liberen, se confisquen o se limpien por mecanismos de limpieza.

Por último, para realizar una reserva persistente y liberarla se utilizan los comandos PERSISTENT RESERVE OUT y PERSISTENT RESERVE IN.

Bien, os preguntaréis cómo se traduce toda esta teoría en algo útil, algo que conozcamos, ¿no?

Empecemos por suponer un cluster Windows Server 2008 de dos nodos con una cabina de discos.

En ese caso, las HBAs de nuestros nodos son los Iniciadores SCSI y los volúmenes de la cabina son los Targets.

Si la HBA1 del nodo 1 tiene el control de los discos 1 y 2 de la cabina, el puerto de la HBA1 será nuestro puerto Iniciador y los puertos de los discos 1 y 2 serán nuestros puertos Target, teniendo así nuestro set I_T Nexus. Por tanto, los discos 1 y 2 solo podrán interpretar comandos lanzados desde el nodo 1. En caso de fallo del nodo 1, el nodo 2 podrá hacerse con el control de los discos confiscando las reservas.

¿Cómo se utilizan las reservas?

Empecemos por el principio… Durante el arranque del cluster el nodo que va a hacerse con el control de uno de los discos intenta reservar el disco de la siguiente forma:

1. El driver de cluster lanza a través de la pila la instrucción para reservar el volumen (IOCTL_STORAGE_PERSISTENT_RESERVE_IN)

2. El driver de disco intercepta el comando y lo transforma en un paquete de Entrada/Salida (IRP) que pasa al driver de Multipathing

3. El driver MPIO pasa la petición al DSM (Device Specific Module). El DSM es el segundo componente de una solución Multipathing dependiente del fabricante de la cabina. Dicho componente debe asegurarse que la petición de reserva se envía a través de todos los caminos.

4. El registro de la reserva se realiza en una tabla de reservas en el inicio del volumen

El mismo procedimiento se sigue para liberar una reserva de un volumen.

Como vemos en los pasos descritos en la imagen anterior, existe una tabla de reservas persistentes con la información de los dispositivos que pueden acceder al volumen. Dicha tabla se almacena al principio del volumen:

Tal y como aparece, el nodo 1 es el que tiene el disco reservado ya que es su clave (key 1) la que está anotada en la tabla. Por tanto será el nodo 1 el que pueda acceder y gestionar el disco. Vemos también que el nodo 2 está intentando registrar una reserva pero será rechazada al existir ya una reserva sobre el disco. Si este intento no es rechazado, el nodo 2 se hará con el control del disco, confiscando así la reserva.

¿Qué problemas puedo encontrarme relacionados con las reservas persistentes?

En numerosas ocasiones nos encontramos con situaciones en las que, tras un reinicio inesperado o algún otro error, uno de los nodos de un cluster no puede unirse al cluster o no se pueden ver los discos desde la consola de cluster. Asimismo, podemos encontrarnos con eventos refiriéndose a un cambio de firmas en los discos o que no se pueden añadir volúmenes nuevos a la pestaña available storage de la consola Failover Cluster Management. Por ejemplo, podemos encontrar los siguientes eventos:

Igualmente, en el log de cluster podemos encontrar (entre otras) entradas como las siguientes:

Esto indica que el comando para liberar la reserva persistente registrada en la tabla de reservas no se ha procesado correctamente y dicha reserva no se ha liberado. En muchas ocasiones ocurre que el otro nodo no ha sido capaz de confiscar dicha reserva y, por tanto, el volumen queda reservado por nadie (no existe el par Iniciador).

Normalmente, esto ocurre cuando el DSM no es capaz de procesar correctamente la petición de liberación de reserva y esta no llega al volumen.

¿Cómo resolvemos un problema de reservas persistentes no liberadas? ¡Quiero que me devuelvan mi cluster!

Como hemos visto, las reservas persistentes son algo que se almacenan en los propios volúmenes de las cabinas de discos. Es por ello que cuando nos encontramos en un escenario de reservas persistentes no liberadas correctamente, es recomendable contactar con el fabricante de la cabina ya que suelen disponer de herramientas específicas para liberar las reservas sin correr el riesgo de borrar ningún otro dato del volumen.

Aun así, en caso de necesitar recuperar urgentemente un cluster, Windows Server 2008 incluye un nuevo comando para liberar las reservas persistentes:

CLUSTER NODE /CLEARPR:disknumber

Este comando se debe lanzar desde uno de los nodos que vea el volumen en el administrador de discos del sistema operativo, que será de donde obtengamos el disknumber.

Hay que tener en mente que este comando solo lo debemos usar en casos realmente urgentes ya que, como decíamos, podemos borrar más información de los volúmenes aparte de las reservas persistentes.

Espero que os haya gustado. ¡Nos vemos en el siguiente post!

Rafael Basterra Careaga
Platforms Support Engineer