Requisitos de herramientas de prueba y pruebas de conformidad con ISCSI

La prueba de conformidad con iSCSI es una prueba para determinar si un iniciador/destino iSCSI cumple con el estándar iSCSI.

Protocolo SCSI y iSCSI

La interfaz de sistema de computadora pequeña ( SCSI ) es una familia de protocolos para comunicarse con dispositivos de E/S, especialmente dispositivos de almacenamiento. SCSI se basa en el modelo cliente-servidor. Los clientes SCSI, llamados "iniciadores", emiten comandos SCSI para solicitar servicios de los componentes, unidades lógicas de un servidor conocido como "destino". Un "transporte SCSI" asigna el protocolo SCSI cliente-servidor a una interconexión específica. Un iniciador es un punto final de un transporte SCSI y un destino es el otro punto final.

El protocolo de Interfaz de sistema de computadora pequeña de Internet ( iSCSI ) utiliza TCP/IP como transporte SCSI. Al transportar paquetes SCSI a través de TCP/IP, iSCSI proporciona una solución interoperable que puede aprovechar la infraestructura de Internet existente, las instalaciones de administración de Internet y las limitaciones de distancia de las direcciones. A diferencia del canal de fibra tradicional, que requiere cableado especial, iSCSI puede ejecutarse en la infraestructura de red existente. Se ha convertido en un protocolo de red de área de almacenamiento (SAN) popular debido a su escalabilidad y beneficios económicos. El protocolo está definido en RFC 3720 y actualizado en RFC 5048.

Pruebas de conformidad con iSCSI

Con el traslado de la capa de transporte SCSI desde la tradicional y confiable estructura de bus a la mucho menos confiable red TCP/IP, se ha introducido una cantidad bastante razonable de complejidad en iSCSI:

Se necesitan procesos de inicio y cierre de sesión.
Los parámetros de seguridad/operativos deben negociarse durante el inicio de sesión.
Se puede utilizar CHAP u otro método de autenticación durante el inicio de sesión.
Es posible que se requieran múltiples sesiones/conexiones.
Se pueden implementar múltiples niveles de recuperación de errores.
...

En una palabra, aunque el coste económico de iSCSI puede ser menor que el de otros, el protocolo en sí no es tan sencillo.

Desde la aprobación del protocolo, iSCSI ha ido ganando aceptación entre los usuarios finales y los proveedores de almacenamiento. Actualmente, existe una gran cantidad de implementaciones de iniciadores/destinos iSCSI en el mercado, ya sean comerciales o de código abierto/gratuito. Estas implementaciones varían en cuanto a funcionalidades y conformidad con el protocolo.

Las pruebas de conformidad son pruebas para determinar si un sistema cumple con algún estándar específico. A menudo, las realizan organizaciones externas, a veces el propio organismo de normalización, para ofrecer mayores garantías de cumplimiento. Los productos probados de esa manera se anuncian como certificados por esa organización externa como conformes con el estándar. Para el protocolo iSCSI (u otros protocolos de redes y almacenamiento de datos), el Laboratorio de Interoperabilidad de la Universidad de New Hampshire (UNH-IOL) es uno de los principales laboratorios independientes neutrales que ofrece conjuntos de pruebas para pruebas de conformidad con iSCSI.

Como dice la parte introductoria de estas suites de pruebas:

Estas pruebas están diseñadas para determinar si un producto iSCSI cumple con las especificaciones definidas en la norma IETF RFC 3720 iSCSI (en adelante denominada la “Norma iSCSI”), así como con las actualizaciones contenidas en la norma IETF RFC 5048 iSCSI Corrections and Clarifications RFC (en adelante denominada “Correcciones y aclaraciones iSCSI”). La finalización exitosa de todas las pruebas contenidas en este conjunto no garantiza que el dispositivo probado funcionará correctamente con otros productos iSCSI. Sin embargo, cuando se combinan con un funcionamiento satisfactorio en el banco de pruebas de interoperabilidad de IOL, estas pruebas brindan un nivel razonable de confianza de que el dispositivo bajo prueba (DUT) funcionará correctamente en muchos entornos iSCSI.

Las pruebas de conformidad iSCSI contienen principalmente los siguientes aspectos:

Conformidad de la fase de inicio de sesión

Pruebe pares clave-valor de negociación; pruebe varios indicadores: CSG, NSG, bit C, bit T...

Conformidad de fase con todas las funciones

Números de secuencia de prueba (CmdSN, DataSN, R2TSN); comando/respuesta SCSI de prueba, solicitud/respuesta de función de gestión de tareas, solicitud/respuesta de texto, NOP-In/NOP-Out, solicitud SNACK...

Conformidad con CHAP

Campos de prueba CHAP: CHAP_A, CHAP_C, CHAP_I, CHAP_N, CHAP_R...

Conformidad con múltiples conexiones

Pruebe el soporte de múltiples conexiones en la creación de conexiones, terminación, negociación de parámetros, números de secuencia y gestión de tareas...

Conformidad con la recuperación de errores

Soporte de recuperación de errores del iniciador/destino de la prueba

Escenarios comunes de pruebas de conformidad con iSCSI

Básicamente se podrían realizar dos tipos de acciones para probar si el DUT cumple con el protocolo iSCSI:

Hacemos las cosas bien y comprobamos si el DUT se comporta correctamente.
En este caso, la tarea principal es enviar una secuencia correcta de PDU iSCSI al DUT y verificar que el DUT pueda responder con los campos de PDU y PDU correctos.
Hacemos cosas mal y vemos si el DUT puede detectarlas y comportarse en consecuencia.
En este caso, debemos modificar la secuencia de PDU enviada al DUT hasta cierto punto (por ejemplo, cambiar CmdSN de un comando, establecer un resumen de datos no válidos...) y verificar que el DUT pueda reaccionar de acuerdo con el protocolo (por ejemplo, enviar un PDU de rechazo, cerrar la conexión...).

Se pueden encontrar algunos escenarios comunes en las pruebas de conformidad con iSCSI:

Prueba funcional iSCSI

Para probar si una tarea iSCSI se puede ejecutar correctamente (función de gestión de tareas, ping NOP-In/NOP-Out, gestión de conexiones múltiples, etc.)

Error de formato de PDU

Por ejemplo, esto es un error si los bits W y F están configurados en 0 en una PDU de comando SCSI.

Error de sesión/etapa de PDU

Por ejemplo, esto es un error si aparece una PDU de comando SCSI en la etapa de inicio de sesión o en la sesión de descubrimiento.

Error de encabezado/resumen de datos

Un error de resumen puede provocar que el destino/iniciador envíe un PDU de rechazo/SNACK.

Error de secuencia

CmdSN/StatSN/DataSN/R2T cada uno tiene un alcance y reglas diferentes.

Error de negociación

Los parámetros de texto deben tener el formato clave=valor, seguido de un delimitador NULL ("0x00"). Cada parámetro de texto también tiene su propia etapa y reglas de negociación. Por ejemplo, FirstBurstLength no debe superar MaxBurstLength, SendTargets debe aparecer solo en la fase de funciones completas, etc.

Error de longitud de datos

Se envían demasiados o muy pocos datos al destino.

PDU perdida

Descarte una PDU entrante y luego SNACK para ella, descarte una PDU saliente y vuelva a intentarlo.

La mayoría de los escenarios anteriores se pueden emular modificando el contenido de la PDU de salida. Por ejemplo, para emular un error de resumen de datos, solo necesitamos cambiar el campo DataDigest en la PDU.

Requisito de la herramienta de prueba de conformidad con iSCSI

Una herramienta de prueba de conformidad con iSCSI puede considerarse como un emulador de iniciador iSCSI (para probar el destino iSCSI) o un emulador de destino iSCSI (para probar el iniciador iSCSI). Una buena herramienta de prueba de conformidad con iSCSI debe cumplir los siguientes requisitos:

Scripts de prueba ejecutables

Se necesita un script ejecutable para cada caso de prueba. Debe escribirse de acuerdo con la descripción del caso de prueba que define la secuencia de PDU y los puntos de verificación.

Un núcleo de motor iSCSI

El núcleo del motor iSCSI se encarga de enviar/recibir PDU iSCSI hacia/desde el DUT (dispositivo bajo prueba). Por un lado, acepta la entrada de un script de prueba, envía PDU o verifica los puntos de control; por otro, debe comprender el protocolo iSCSI hasta cierto nivel para que se pueda lograr la automatización necesaria, por ejemplo, la generación automática de PDU iSCSI (solicitud de inicio de sesión/texto durante la negociación, respuesta de ping Nop-Out) y algunos campos de PDU (ITT, TTT, CmdSN, datos, resumen...).

Validación del formato PDU

Para las PDU recibidas, el núcleo del motor iSCSI debe realizar una verificación de validación para detectar PDU malformadas.

Capacidad de modificar el contenido de la PDU

Las PDU malformadas a menudo se envían al DUT para simular un error de formato de PDU o un error de resumen.

Capacidad de eliminar PDU

Se podría descartar una PDU para simular una PDU perdida durante la transmisión.

Capacidad de mantener múltiples sesiones/conexiones

Al igual que la recuperación de errores, la compatibilidad con múltiples sesiones/conexiones es un campo avanzado en el protocolo iSCSI.

Resultado y registro

El resultado de una prueba aprobada o reprobada debe tener una indicación clara. Se necesita un registro detallado para el análisis. Sería mejor tener una interfaz gráfica para analizar los archivos de volcado de PDU.

Un sistema por lotes

Se necesita un sistema por lotes para administrar conjuntos de pruebas y casos de prueba, de modo que una gran cantidad de scripts de prueba puedan ejecutarse automáticamente sin intervención del usuario.

Herramientas de prueba de conformidad con iSCSI disponibles