Redfish
Referencia del driver Redfish: conexión HTTPS a un BMC, direccionamiento por ruta de recurso más puntero JSON, lecturas, escrituras PATCH y tipos.
El driver Redfish lee y escribe servicios de administración Redfish de la DMTF: la API REST que exponen los BMC de servidor (baseboard management controllers), los chasis y otro hardware de centro de datos para la administración fuera de banda. Este es un driver ordinario en modo cliente (Ganter Lab se conecta al equipo) y el transporte siempre es HTTPS: los BMC endurecidos no exponen nada más, y el driver nunca baja por su cuenta a HTTP sin cifrar.
Puntos típicos que se leen así: el estado de energía, el estado del arranque seguro, la salud del chasis y del manager, la versión de firmware, y las temperaturas y las lecturas de ventilador de los recursos térmicos.
Los campos de conexión
| Campo | Qué es | Formato | Valor inicial |
|---|---|---|---|
| Host o IP | El nombre de host o la dirección IP del servicio Redfish. | Nombre de host o IP | vacío |
| Puerto | El puerto en el que contesta el servicio. Los controladores de administración suelen contestar en el 443, y un servicio publicado en otro lado lo dice aquí. | de 1 a 65535 | 443 |
| Nombre de usuario | La cuenta del BMC que se usa para la autenticación HTTP Basic. Vacío deja las peticiones anónimas, y un servicio protegido las contestará con un error de autorización. | Texto libre | vacío |
| Contraseña | La contraseña que va con el nombre de usuario. Protegida en reposo por usuario de Windows, así que la base de datos de configuración nunca guarda el valor en claro; una contraseña capturada en otra cuenta de Windows se muestra como ilegible y hay que volver a ingresarla. | Texto libre | vacía |
Al conectarse, el driver verifica el servicio leyendo la raíz del servicio
(/redfish/v1/). El certificado TLS del BMC tiene que pasar la validación normal de
certificados de Windows: un certificado autofirmado de un BMC tiene que ser de confianza de
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 de fondo detrás, así que
una contraseña rechazada y un certificado sin confianza se distinguen.
El intervalo de sondeo es configurable: el valor predeterminado del dispositivo (1000 ms) vale para todo tag que no declare el suyo.
El direccionamiento del tag
Un tag de Redfish se direcciona con una ruta del recurso más un puntero JSON opcional dentro del documento que devuelve ese recurso:
| Campo | Qué hace | Valores | Valor inicial |
|---|---|---|---|
| Ruta del recurso | La ruta del recurso Redfish que se hace GET, relativa a la raíz del servicio, por ejemplo redfish/v1/Chassis/1/Thermal. |
Texto libre (obligatorio) | vacía |
| Puntero JSON (en blanco = documento completo) | Un puntero RFC 6901 que elige un campo del JSON devuelto, por ejemplo /Temperatures/0/ReadingCelsius. Los elementos de un arreglo se direccionan por índice; ~1 escapa una / dentro de un nombre de campo y ~0 una ~. Si falta la / inicial, se agrega por usted. En blanco devuelve el documento completo como texto. |
Puntero JSON o en blanco | en blanco |
Ejemplos de la dirección armada (mostrada de solo lectura como la vista previa del origen en el bus):
redfish/v1/Systems/1#/PowerState, el estado de energía 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 driver hace GET del recurso, interpreta el JSON, sigue el puntero y
convierte el resultado al tipo de dato declarado del tag. Un puntero que no nombra nada
dentro del 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 lectura fallida decide qué se
presenta, en lugar de que la palabra null llegue como una lectura buena. Una respuesta que
no es JSON se interpreta directamente como el tipo declarado.
Las escrituras
Los tags con un modo de acceso escribible hacen PATCH del campo direccionado: el driver arma
el documento JSON más pequeño que cubra solo la ruta del puntero (para /Parent/Child, el
cuerpo {"Parent":{"Child":<valor>}}) y lo envía al recurso. De ahí salen dos
restricciones:
- Una escritura necesita un puntero JSON. Un tag de documento completo (con el puntero en blanco) no se puede escribir: el panel del tag rechaza la combinación mientras usted edita, diciendo que falta el campo, y un intento que llegue al servicio de todos modos falla con el motivo en el diario técnico.
- El BMC decide qué es escribible; un PATCH que el servicio rechaza se lee como una escritura fallida.
Como en todos lados, el valor que usted escribe en la caja 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, como se describe en la página del Connector.
Los tipos de dato admitidos
Boolean, Int32, Int64, Float, Double y String. Elija el tipo que corresponda al campo JSON:
booleanos para banderas como SecureBootEnable, números para las lecturas, textos para
estados como PowerState o Health.
Los 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 hardware dice cuáles existen: usted las declara 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, opcionalmente, el nombre del único
valor que toma (ResetType); el verbo Ejecutar de la fila lo envía, y lo que contestó el
servicio se reporta de vuelta. Un comando se convierte además en un método del dispositivo
dentro del espacio de direcciones OPC UA propio de esta estación, así que cualquier cosa que
pueda llamar a un método puede lanzarlo.
El valor viaja como el cuerpo de la petición. Un valor que ya es JSON se envía tal como se escribió;
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.
El descubrimiento
El botón Descubrir lee un solo servicio: ponga su dirección en la tarjeta Alcance del
escaneo de la página del driver (https://bmc-host, o la dirección que documente el
fabricante) y el escaneo recorre el primer sistema, el primer manager y el primer chasis de
ese servicio, ofreciendo el dispositivo con esos puntos listos para agregarse. El escaneo lee
el servicio por HTTPS y sin credenciales, porque corre antes de que exista el dispositivo que
las tendría, así que un servicio que autentica cada petición no contesta nada y se agrega a
mano en su lugar. El descubrimiento propio de Redfish por SSDP necesita multidifusión UDP, que
el driver dentro del proceso no hace, así que nada se encuentra por difusión: el escaneo lee
la dirección que usted le dé.