Redfish

Referencia del controlador Redfish: conexión HTTPS a un BMC, direccionamiento por ruta del recurso más puntero JSON, lecturas, escrituras PATCH y tipos.

El controlador Redfish lee y escribe servicios de gestión DMTF Redfish: la API REST que exponen los BMC de servidor (controladores de gestión de la placa base), los chasis y otro hardware de centro de datos para la gestión fuera de banda. Es un controlador en modo cliente corriente (Ganter Lab se conecta al equipo) y el transporte es siempre HTTPS: los BMC endurecidos no exponen ninguna otra cosa, y el controlador nunca baja por su cuenta a HTTP sin cifrar.

Puntos típicos que se leen así: el estado de alimentación, el estado del arranque seguro, el estado de salud del chasis y del gestor, la versión del firmware, y las temperaturas y las lecturas de ventilador de los recursos térmicos.

Campos de conexión

Al conectar, el controlador verifica el servicio leyendo la raíz del servicio (/redfish/v1/). El certificado TLS del BMC tiene que pasar la validación de certificados normal de Windows: un certificado de BMC autofirmado tiene que estar aprobado en esta máquina antes de que el dispositivo se conecte. Una conexión que falla dice por qué en la página Eventos y en el archivo de registro del día, con el error subyacente detrás, para que una contraseña rechazada y un certificado no aprobado se distingan.

El intervalo de sondeo es configurable: el valor por defecto del dispositivo (1000 ms) se aplica a todo tag que no declare el suyo.

Direccionamiento del tag

Un tag Redfish se direcciona con una ruta del recurso más un puntero JSON opcional dentro del documento que devuelve ese recurso:

Ejemplos de la dirección ya compuesta (mostrada de solo lectura como vista previa del origen en el bus):

• redfish/v1/Systems/1#/PowerState, el estado de alimentación del sistema, como texto.
• redfish/v1/Chassis/1/Thermal#/Temperatures/0/ReadingCelsius, el primer sensor térmico, como número.
• redfish/v1/Systems/1/SecureBoot#/SecureBootEnable, el arranque seguro, como booleano.

En una lectura, el controlador hace GET al recurso, analiza el JSON, sigue el puntero y convierte el resultado al tipo de dato declarado del tag. Un puntero que no nombra nada en el documento, y un campo que el documento lleva como null de JSON, se leen los dos como sin valor: el tag pasa a mala calidad y su política de fallo de lectura decide qué se presenta, en lugar de que la palabra null llegue como una lectura buena. Una respuesta que no es JSON se analiza directamente según el tipo declarado.

Escrituras

Los tags con un modo de acceso que permite escribir hacen PATCH sobre el campo direccionado: el controlador construye el documento JSON más pequeño que cubre solo la ruta del puntero (para /Parent/Child, el cuerpo {"Parent":{"Child":<value>}}) y lo envía al recurso. De ahí se siguen dos restricciones:

• Una escritura exige un puntero JSON. Un tag de documento completo (puntero en blanco) no se puede escribir: el panel del tag rechaza la combinación mientras se edita, diciendo que falta el campo, y un intento que llegue de todos modos al servicio falla con el motivo en el diario técnico.
• El BMC decide qué se puede escribir; un PATCH que el servicio rechaza se lee como una escritura fallida.

Como en todas partes, el valor que se escribe en la casilla de escritura del tag es el valor de ingeniería, y las etapas de conversión del tag se deshacen antes de que el valor bruto salga al bus, tal como se describe en la página Connector.

Tipos de dato admitidos

Boolean, Int32, Int64, Float, Double y String. Elija el tipo que se corresponda con el campo JSON: booleanos para las banderas como SecureBootEnable, números para las lecturas, y texto para los estados como PowerState o Health.

Comandos

Un servicio Redfish publica una acción por cada cosa que se le puede pedir, cada una en su propia ruta bajo el recurso sobre el que actúa. La estación no las adivina, porque solo la documentación del propio hardware dice cuáles existen: se declaran en el dispositivo, en la tarjeta Comandos de su página. Cada comando lleva un nombre, la ruta de la acción (redfish/v1/Systems/1/Actions/ComputerSystem.Reset) y, si procede, el nombre del único valor que toma (ResetType); el verbo Ejecutar de la fila lo envía, y lo que contestó el servicio se informa de vuelta. Un comando pasa a ser además un método sobre el dispositivo en el espacio de direcciones OPC UA propio de esta estación, así que cualquiera que pueda llamar a un método lo puede emitir.

El valor viaja como cuerpo de la petición. Un valor que ya es JSON se envía tal como está escrito; cualquier otra cosa se envía como {"<el nombre que usted declaró>": "<el valor>"}, que es la forma que espera la propia acción de reinicio de Redfish.

Descubrimiento

El botón Descubrir lee un servicio: ponga su dirección en la tarjeta Alcance de la exploración de la página del controlador (https://bmc-host, o la dirección que documente el fabricante) y la exploración recorre el primer sistema, el primer gestor y el primer chasis de ese servicio, ofreciendo el dispositivo con esos puntos listos para añadir. La exploración lee el servicio por HTTPS y sin credenciales, porque corre antes de que exista el dispositivo que las guardaría, así que un servicio que autentica cada petición no responde nada y se añade a mano. El descubrimiento SSDP propio de Redfish necesita multidifusión UDP, que el controlador en proceso no hace, así que difundiendo no se encuentra nada: la exploración lee la dirección que se le dé.