Redfish

Redfish 드라이버 참고 자료입니다. BMC로의 HTTPS 연결, 리소스 경로와 JSON 포인터로 적는 주소, 읽기, PATCH 쓰기, 그리고 형식.

Redfish 드라이버는 DMTF Redfish 관리 서비스를 읽고 씁니다. 대역 외 관리를 위해 서버 BMC(베이스보드 관리 컨트롤러)와 섀시와 그 밖의 데이터센터 하드웨어가 내놓는 REST API입니다. 이것은 평범한 클라이언트 모드 드라이버, 곧 Ganter Lab이 장비에 접속하는 드라이버이며 전송은 언제나 HTTPS입니다. 단단히 잠근 BMC는 그 밖의 것을 내놓지 않고, 드라이버도 스스로 평문 HTTP로 내려가지 않습니다.

이렇게 읽는 대표적인 지점은 전원 상태, 보안 부팅 상태, 섀시와 매니저의 상태 건전성, 펌웨어 버전, 그리고 열 관련 리소스에서 오는 온도와 팬 읽기입니다.

연결 칸

접속할 때 드라이버는 서비스 뿌리(/redfish/v1/)를 읽어 서비스를 확인합니다. BMC의 TLS 인증서는 Windows가 신뢰하거나, 이 드라이버 페이지의 현장 장비 접근에서 바로 그 인증서를 승인했을 때 받아들여집니다. BMC가 출고 때부터 지닌 자체 서명 인증서 때문에 Windows에 무엇을 설치할 필요는 없습니다. 실패한 연결은 Events 페이지와 그날의 로그 파일에 이유를 적으며 그 뒤에 바탕 오류를 함께 적으므로, 거부된 비밀번호와 승인을 기다리는 인증서를 가려낼 수 있습니다.

읽기 주기는 설정할 수 있습니다. 스스로 값을 정하지 않은 모든 태그에는 장치의 기본값(1000 ms)이 적용됩니다.

태그 주소 지정

Redfish 태그의 주소는 리소스 경로와, 그 리소스가 돌려주는 문서 안을 가리키는 선택적인 JSON 포인터로 적습니다.

조립된 주소의 예는 이렇습니다(버스 신호원 미리 보기에 읽기 전용으로 나옵니다).

• redfish/v1/Systems/1#/PowerState는 시스템의 전원 상태를 문자열로 읽습니다.
• redfish/v1/Chassis/1/Thermal#/Temperatures/0/ReadingCelsius는 첫 번째 온도 센서를 숫자로 읽습니다.
• redfish/v1/Systems/1/SecureBoot#/SecureBootEnable은 보안 부팅을 부울로 읽습니다.

읽을 때 드라이버는 리소스에 GET을 보내고 JSON을 해석한 다음 포인터를 따라가, 그 결과를 태그가 선언한 데이터 형식으로 바꿉니다. 문서에서 아무것도 가리키지 못하는 포인터와, 문서가 JSON null로 담고 있는 필드는 둘 다 값 없음으로 읽힙니다. null이라는 낱말이 정상 읽기로 도착하는 대신 태그는 품질이 나쁜 것이 되고, 무엇을 보여 줄지는 그 읽기 실패 정책이 정합니다. JSON이 아닌 응답은 선언한 형식으로 곧바로 해석합니다. 서비스가 성공 범위 밖의 상태를 돌려주는 것은 서비스가 읽기를 거부한 것입니다. 태그는 똑같이 품질이 나쁜 것이 되고, 그 이유는 상태와 서비스가 함께 보낸 오류 문서의 짧은 발췌(HTTP 404 Not Found: …)를 밝힙니다. 값이 없는 다른 읽기도 이유를 말합니다. 리소스 경로가 없는 태그, 문서에서 아무것도 가리키지 못하는 포인터와 null로 담긴 필드(각각 리소스와 포인터를 밝힙니다), 그리고 선언한 형식으로 읽히지 않는 응답입니다. 아예 답하지 않는 서비스는 장치의 연결이 실패한 것입니다. 장치가 그것을 알리고 다시 연결하며, 그 태그들은 장치를 가리킵니다. 태그의 빨간 줄은 이런 상태를 스테이션의 언어로 전하고 401, 403, 404에는 그 뜻이 붙으며, 장치의 빨간 줄은 매 시도마다 연결이 실패하는 이유(거부하는 포트나 401 같은 상태)를 전합니다. 서비스 자신의 말은 이벤트 페이지에 남습니다.

쓰기

쓸 수 있는 접근 방식을 가진 태그는 주소가 가리키는 필드에 PATCH를 보냅니다. 드라이버는 포인터의 경로만 덮는 가장 작은 JSON 문서를 만들어(/Parent/Child라면 본문은 {"Parent":{"Child":<value>}}입니다) 리소스로 보냅니다. 여기에서 제약 둘이 따라옵니다.

• 쓰기에는 JSON 포인터가 필요합니다. 문서 전체를 가리키는 태그(포인터가 비어 있는 태그)에는 쓸 수 없습니다. 태그 패널은 편집하는 동안 그 조합을 거부하며 칸이 빠졌다고 말하고, 그래도 서비스까지 닿은 시도는 이유를 진단 로그에 남기며 실패합니다.
• 무엇을 쓸 수 있는지는 BMC가 정합니다. 서비스가 거부한 PATCH에는 상태와, 서비스가 함께 보낸 오류 문서의 짧은 발췌(HTTP 400 Bad Request: …)가 답으로 돌아가므로 값을 쓴 쪽이 이유를 읽을 수 있습니다.

다른 곳에서와 마찬가지로 태그의 쓰기 상자에 입력하는 값은 공학값이며, Connector 페이지에서 설명하듯 원시값이 버스로 나가기 전에 태그의 변환 단계가 거꾸로 적용됩니다.

지원하는 데이터 형식

Boolean, Int32, Int64, Float, Double, String입니다. JSON 필드에 맞는 형식을 고르십시오. SecureBootEnable 같은 플래그에는 부울, 읽은 값에는 숫자, PowerState나 Health 같은 상태에는 문자열입니다.

명령

Redfish 서비스는 시킬 수 있는 일마다 액션을 하나씩 공개하며, 각각은 자기가 작용하는 리소스 아래 자기 경로에 있습니다. 스테이션은 그것을 추측하지 않습니다. 어떤 액션이 있는지는 하드웨어 자신의 설명서만이 말해 주기 때문입니다. 명령은 장치의 페이지에 있는 명령 카드에서 직접 선언합니다. 명령마다 이름과 액션 경로(redfish/v1/Systems/1/Actions/ComputerSystem.Reset), 그리고 원한다면 명령이 받는 값 하나의 이름(ResetType)을 담습니다. 행의 실행 동사가 명령을 보내고, 서비스가 무엇이라고 답했는지 알려 줍니다. 명령은 이 스테이션 자신의 OPC UA 주소 공간에서 장치의 메서드가 되기도 하므로, 메서드를 부를 수 있는 것이라면 무엇이든 그 명령을 낼 수 있습니다.

값은 요청 본문으로 실려 갑니다. 이미 JSON인 값은 적은 그대로 나가고, 그 밖의 것은 {"<선언한 이름>": "<값>"} 모양으로 나갑니다. 이것이 Redfish 자신의 리셋 액션이 기대하는 모양입니다.

서비스가 거부한 액션에는 상태와, 서비스가 함께 보낸 오류 문서의 짧은 발췌(HTTP 400 Bad Request: …)가 답으로 돌아갑니다. 거부된 쓰기와 같은 말이며, 그것 때문에 그 장치의 다른 무엇이 흔들리지는 않습니다.

장치 검색

장치 검색 단추는 서비스 하나를 읽습니다. 드라이버 페이지의 스캔 범위 카드에 그 주소(https://bmc-host, 또는 제조사가 설명하는 주소)를 적으면 스캔이 그 서비스의 첫 시스템과 매니저와 섀시를 훑어, 그 지점들을 갖춘 장치를 바로 추가할 수 있게 내놓습니다. 스캔은 HTTPS로, 자격 증명 없이 서비스를 읽습니다. 자격 증명을 담고 있을 장치가 생기기 전에 도는 스캔이기 때문입니다. 그러므로 요청마다 인증을 요구하는 서비스는 아무것도 답하지 않으며, 그런 서비스는 손으로 추가합니다. Redfish 자신의 SSDP 검색은 UDP 멀티캐스트를 쓰는데 인프로세스 드라이버는 그것을 하지 않으므로, 브로드캐스트로 찾아지는 것은 없습니다. 스캔은 사용자가 건네준 주소를 읽습니다.

이미 있는 Redfish 장치는 자기 페이지에서 지점을 찾습니다. 태그 카드 머리의 태그 검색은 장치의 사용자 이름과 암호로 로그인해 같은 리소스를 훑으므로 요청마다 인증을 요구하는 서비스도 답하며, 장치에 아직 태그가 없는 지점만 제시합니다(장치의 태그 검색 참고).

현장 장비 접근

BMC는 대개 자체 서명했거나 제조사가 발급한 자기 인증서로 응답하며, Windows에 설치된 어떤 루트도 그 인증서를 보증하지 않습니다. 그 루트를 이 컴퓨터에 설치할 필요는 없습니다. 첫 연결은 거부되고, 장치는 트리와 그 페이지에서 인증서 승인 대기 중으로 표시되며, 그 페이지의 인증서 검토 단추가 이 카드를 그 인증서 위치에서 엽니다. 인증서는 Redfish 드라이버 페이지 끝의 현장 장비 접근에서 결정을 기다립니다. OPC UA 드라이버 페이지에 있는 것과 같은 카드입니다.

승인하기 전에 서버를 관리하는 담당자와 함께 지문을 확인하십시오. 승인은 그 인증서 하나만, 그것도 유효 기간 안에서만 받아들입니다. 승인은 Windows에 없는 루트와 인증서에 적힌 이름을 대신하므로, IP 주소로 접속하는 BMC도 인증서에 다른 이름이 적혀 있어도 연결되며, 인증서의 다른 점은 아무것도 느슨해지지 않습니다. 승인한 인증서의 주소에서 장비가 다른 인증서를 내놓으면(인증서 갱신, 컨트롤러 교체 등) 읽기가 멈추고, 새 인증서가 여기에서 기다리며, 스테이션이 검토 단추와 함께 "인증서가 바뀜: <이름>"을 알립니다. Windows가 이미 신뢰하는 인증서는 예전처럼 받아들여지고 여기에는 나타나지 않습니다. 자동으로 승인되는 것은 없습니다.

드라이버 자체의 실패는 이름 없는 TLS 오류 대신 이유를 말합니다. "이 현장 장비의 인증서(지문의 앞 16자)가 Redfish 드라이버 페이지의 현장 장비 접근에서 승인을 기다립니다. 승인하면 읽기가 시작됩니다." 차단한 인증서라면 "…은 이 스테이션에서 차단되었습니다. Redfish 드라이버 페이지의 현장 장비 접근에서 검토하십시오."라고 읽힙니다. 유효 기간을 벗어났거나, 해지되었거나, 서명이 깨진 인증서는 그 이유로 거부되고 목록에 오르지 않습니다. 승인해도 건전해지지 않기 때문입니다. 스캔 범위 카드에서 하든, 장치 페이지의 태그 검색에서 하든 BMC 스캔도 같은 결정을 따릅니다. 모르는 인증서는 그 문장으로 스캔을 끝내고 여기에서 기다립니다.

결정은 스테이션 데이터 폴더의 ua\pki\redfish에 저장되며 다시 시작해도 남습니다. 동작 단추는 Connector를 구성할 수 있는 역할에만 그려지고, 스테이션 자신의 창에서만 동작합니다. 다른 기기의 브라우저는 카드를 읽기만 하고 바꾸지 못하며, 에이전트 도구는 인증서를 승인하지 않습니다(connector_browse는 기다리는 장치를 awaitingCertificate로 알립니다). 목록에는 승인 대기 중인 인증서를 100개까지 둡니다. 가득 차면 새 인증서는 계속 거부되지만 목록에 오르지 않으며, 카드가 그렇다고 알립니다.