요약

  • RFC 7147은 iSCSIProtocolLevel을 개별 세션의 속성에 배치하여 이니시에이터–타깃 협상의 범위를 그대로 보존했다.
  • 레벨 2 값은 프로토콜 상태에 대한 근거이며, SCSI 작업 성공이나 애플리케이션 결과에 대한 영수증이 아니다.

기기가 자기 자신과 협상하지는 않았다

스토리지 대시보드는 종종 하나의 안심되는 레이블을 원한다. 지원됨, 최신, 호환 가능. 그러나 iSCSI 기능을 갖춘 시스템은 하나의 대화가 아니다. 하나의 시스템 안에 여러 인스턴스, 노드, 포털, 세션, TCP 연결이 존재할 수 있다. 각 세션은 하나의 이니시에이터와 하나의 타깃을 연결한다. 피어들은 그 관계 위에서 프로토콜 키를 협상하며, 다른 세션은 다른 피어, 다른 이력, 다른 협상 상태를 가질 수 있다.

이 구분이야말로 RFC 7147에 담긴 유용한 이야기다. 2014년 4월에 발표된 이 RFC는 RFC 4544의 iSCSI 관리 정보 베이스(MIB)를 RFC 7143과 RFC 7144에 맞춰 갱신한 문서로 대체했다. 이 갱신은 세션 테이블에 두 개의 속성을 추가했다: iscsiSsnProtocolLevel과 iscsiSsnTaskReporting. 둘 다 읽기 전용이다. 첫 번째는 해당 세션에 대해 협상된 iSCSI 프로토콜 레벨을 기술하고, 두 번째는 SCSI 타깃으로부터 협상된 작업 완료 보고 의미론을 기록한다.

이 행은 숫자를 저장하기 편한 장소 그 이상이다. 이 행은 누가 누구와 합의했는지를 보존한다. 어플라이언스 전체에 붙은 값은 한 이니시에이터의 세션을 다른 세션과 뒤섞고, 관계를 제품 주장으로 바꿔버릴 것이다. RFC 7147은 대신 프로토콜 자체의 경계를 따랐다. 키는 세션을 위해 협상되었으므로, 관리 항목도 그 세션으로 색인된다.

레벨은 합의였지 기능 목록이 아니었다

RFC 7144는 레벨 2에 구체적인 역할을 부여한다. 그곳에서 기술하는 기능들을 사용하려면 iSCSIProtocolLevel 키를 협상해야 한다. 그러나 이 RFC는 한계도 명확히 그어 놓았다. 레벨 2 협상은 관련 SCSI 기능을 사용하기 위한 필요 조건이지 충분 조건이 아니다. 타깃은 특정 작업 관리 기능을 여전히 거부할 수 있다. 이니시에이터는 SCSI 응답을 평가해야 하며, 관리 읽기가 그 자리를 대신할 수 없다.

협상된 값이 대시보드 배지가 되면 이 점을 잃기 쉽다. "레벨 2"는 모든 기능이 작동한다는 기기 전체의 약속처럼 들릴 수 있다. 그러나 프로토콜에서 그것은 더 좁다. 하나의 세션의 양쪽 끝이 관련 프로토콜 레벨에 합의했다는 것뿐이다. 그 합의는 특정 기능을 사용할 수 있는 길을 열 뿐이며, 구현 지원, 실제로 보낸 요청, 타깃의 응답, 소비자의 해석은 여전히 별개의 사실로 남는다.

RFC 7147은 두 번째 새 속성에서도 같은 주의를 드러낸다. TaskReporting은 협상된 보고 의미론의 집합으로, RFC 3720 기준선, ResponseFence, FastAbort를 포함한다. 이것은 작업 완료가 어떻게 보고되어야 하는지를 말한다. 특정 작업이 완료되었는지, 데이터가 영구화되었는지, 애플리케이션이 결과를 수용했는지는 말하지 않는다.

관리 트리는 경계를 보이게 유지했다

이 MIB는 iSCSI 인스턴스에서 시작하여 노드, 포털, 세션, 연결을 연관시킨다. 스칼라가 아닌 각 항목은 우선 인스턴스로 색인된다. 그 인스턴스는 물리적 또는 가상 파티션을 나타낼 수 있으며, 규모가 크거나 계층적인 스토리지 시스템에서 유용하다. RFC 7147은 인스턴스가 SNMP 컨텍스트를 대체하지 않도록 신경 썼다. 인스턴스는 모든 행마다 매핑을 반복하지 않고도 하나의 파티션을 하나 이상의 컨텍스트에 대응시키는 간단한 방법을 제공할 뿐이다.

이 아키텍처는 운영팀이 하나로 뭉칠 수 있었던 여러 질문을 분리한다. 세션 테이블은 협상된 iSCSI 상태를 보고할 수 있다. TCP MIB는 전송 계층 연결을 기술한다. SCSI MIB는 SCSI 계층 속성을 다룰 수 있다. 호스트나 애플리케이션은 여전히 자기만의 성공 기준을 갖는다. 한 관리 평면이 운영자가 이 기록들 사이를 이동하도록 도울 수 있지만, 기록의 존재가 그것들을 하나의 증명으로 접어버리지는 않는다.

이것은 작고 실용적인 규모에서의 실행 코드 우위성이다. 명세는 이니시에이터와 타깃이 그것을 구현하고, 협상하고, 명령을 주고받을 때 의미가 있다. MIB는 운영자가 그 실행 중인 시스템에서 정의된 상태를 관찰할 수 있을 때 의미가 있다. 그러나 관찰은 어디까지나 특정 계층의 특정 시점에 대한 관찰이다. 어떤 작업이 성공했다고 주장하려면, 근거를 응답과 그것을 필요로 한 소비자까지 따라가야 한다.

그 숫자가 뒷받침할 수 있는 것

운영자에게 세션 단위의 레벨은 동일한 스토리지 시스템으로 가는 두 경로가 왜 다르게 동작하는지 설명해줄 수 있다. 호환성 조사, 변경 검토, 장애 분류를 뒷받침할 수도 있다. 설정이 기대한 것과 실제 세션이 협상한 것 사이의 불일치를 드러낼 수도 있다. 이 숫자가 유용한 것은 바로 기기 전체를 요약하는 척하지 않기 때문이다.

한계 역시 똑같이 중요하다. RFC 7147은 관리 항목을 정의할 뿐, 몇 벤더가 그것을 구현했는지, 얼마나 자주 폴링되었는지, 고객이 그것에 의존했는지는 보고하지 않는다. 수집된 값에는 세션 식별자와 관찰 시각도 필요하다. 세션이 교체되었다면 과거 샘플은 현재 경로에 대한 증거가 아니다. 스토리지 작업이 성공했는지가 문제라면, 어떤 RFC 필드도 상호 연관된 SCSI 응답, 호스트 기록, 애플리케이션 수준 테스트를 대신할 수 없다.

지속되는 교훈은 소박하지만 중요하다. 프로토콜 레벨은 그 레벨을 만든 합의에 속한다. RFC 7147은 그 합의에 자기 자신의 행을 주었고, 다음 근거 질문은 열어 두었다.

출처