요약

  • SNMP RowStatus는 세 가지 관측 가능한 조건을 구분했습니다. 개념적 행은 필요한 정보가 없는 상태로 존재할 수 있고, 완전했지만 의도적으로 서비스에서 제외될 수 있으며, 관리 대상 장치가 사용할 수 있는 활성 상태일 수 있습니다.
  • createAndGo,createAndWait,destroy는 요청이며 GET이 반환하는 상태가 아닙니다. 관리자가 의도를 표현하고, 에이전트가 MIB의 규칙을 적용해 요청된 전환이 허용 가능한지 판단합니다.

테이블은 데이터베이스가 아니라 약속이었다

초기의 관리 정보 베이스는 편안하게 표 형태로 보였습니다. 관리자는 객체 식별자를 지정하고 인스턴스 인덱스를 추가한 뒤, 표준이 개념적 행(conceptual row)이라 부른 것의 한 열을 읽거나 썼습니다. 이 시각적 유추는 위험한 가정을 부추겼습니다. 셀이 존재하면 구성도 모든 의미 있는 면에서 존재한다는 가정이었습니다.

1991년에 발표된RFC 1212는 더 신중했습니다. 이 문서는 테이블과 행을 응용이 부과한 관례로 설명했습니다. SNMP는 완전한 행을 자동으로 만들거나, 의존성을 강제하거나, 절반만 만들어진 항목을 안전하게 사용 가능하게 만드는 관계형 모델을 전달하지 않았습니다. MIB는 삭제용 상태 정수를 정의할 수 있고, 에이전트는 아직 존재하지 않는 인스턴스를 지명하는 SetRequest를 수락할 수 있으며, 기본값이 생략된 열을 채울 수 있었습니다. 그러나 각 MIB는 여전히 그러한 행위가 무엇을 의미하는지 설명해야 했습니다.

이 느슨함은 대부분의 테이블이 장치가 생성하는 관측 데이터였을 때는 견딜 수 있었습니다. 여러 관리 스테이션이 구성을 만들 수 있게 되면서 협조 문제가 되었습니다. 어느 쓰기가 선택된 인덱스를 확보하는가? 불완전한 행은 언제 실제가 되는가? 두 번째 관리자가 볼 수 있는가? 관리 대상 장치가 언제 그것에 따라 동작할 수 있는가?

RMON은 미완성 행을 드러냈다

RFC 1271의 원격 네트워크 모니터링 MIB(RMON)는 중요한 선례를 제공했습니다. 그EntryStatus는 항목 생성 요청과underCreation(생성 중) 항목,valid(유효) 항목,invalid(무효) 항목을 구분했습니다. 관리자는 행을 예약하고, 채워 넣고, 그 후에야 유효하게 만들 수 있었습니다. 두 관리자가 같은 인덱스의 행을 만들려 하면, 첫 번째 성공한 요청만 이기고 나머지는 오류를 받았습니다.

RMON은 또한 소유자(owner) 문자열을 붙여 관리 스테이션이 자원의 생성자를 식별하고 협력할 수 있게 했습니다. 문서는 그 한계를 명확히 밝혔습니다. 소유권 정보는 접근 제어가 아닙니다. 비협조적 관리자는 여전히 항목을 변경하거나 삭제할 수 있었습니다. 귀속(attribution)은 협조에 도움을 주었지만 권한을 만들어내지는 않았습니다.

이 구분은 구성 시스템이 레이블을 과대해석하는 경우가 많기 때문에 중요합니다. 생성자 필드는 인증이 아닙니다. 행의 존재는 준비 완료가 아닙니다. 상태 값은 그것에 의미를 부여하는 정확한 전이 규칙 안에서만 유용합니다.

여섯 값을 상태와 동작으로 나누다

SNMPv2는RFC 1443에서 더 넓은 해결책을 표준화했습니다.RFC 2579의 현재 정의도 여섯 개의 RowStatus 값을 유지하지만, 이들은 같은 종류의 여섯 상태를 설명하지 않습니다.

세 값은 관측 가능합니다.active(1)은 행이 관리 대상 장치에서 사용 가능함을 뜻합니다.notInService(2)는 행이 존재하지만 사용 불가능함을 뜻하며, 에이전트는 활성화를 시도할 만큼의 정보는 가지고 있습니다. 이 값은 행이 내부적으로 일관성이 있거나, 자원이 사용 가능하거나, 장치의 현재 조건에서 활성화가 성공할 것임을 보장하지 않습니다.notReady(3)는 행이 존재하지만 하나 이상의 필수 열 인스턴스가 없음을 뜻합니다.

다른 세 값은 SetRequest에 담기는 동작입니다.createAndGo(4)는 에이전트에게 새 행을 만들어 활성화하라고 요청합니다.createAndWait(5)는 행을 서비스에 넣지 않고 만들라고 요청합니다.destroy(6)는 행에 속한 모든 인스턴스를 제거하라고 요청합니다.

GET은 결코createAndGo,createAndWait,destroy를 반환하지 않습니다. 존재하는 행에 대해서는active,notInService,notReady만 반환합니다. 관리자가notReady를 설정하는 것도 허용되지 않습니다. 그것은 누락된 정보에 대한 에이전트의 보고입니다. 따라서 이 어휘는 명령과 증거가 같은 값을 차지하지 않게 합니다.

생성과 이동은 전부이거나 전무였다

한 단계 생성은 하나의 요청으로 워크플로를 압축하기 때문에 매력적입니다. 관리자는 사용되지 않은 인스턴스 식별자를 선택하고 필수 열 값과 RowStatus=createAndGo를 함께 보냅니다. 에이전트가 제공하는 기본값이 나머지를 채울 수 있습니다.

결과는 의도적으로 엄격합니다. 에이전트가 행을 사용 가능하게 할 만큼 충분한 정보를 가지면, 행을 만들고 읽을 수 있는 상태는 즉시active가 됩니다. 정보가 불충분하면inconsistentValue오류로 작업이 실패하고 행은 만들어지지 않습니다.

관리자가 수습할 수 있도록 남겨지는 표준화된 절반 행은 없습니다. 실패 응답은 "임시 저장됨"을 의미하지 않습니다. 관리자는 누락된 요건을 찾아 재시도하거나, 에이전트가 지원한다면 단계적 생성을 선택해야 합니다. 한 메시지가 생성과 활성화를 결합할 수 있는 것은 오직 실패가 그 경계를 보존하기 때문입니다.

생성 후 대기는 불완전성을 보이게 만들었다

createAndWait는 다른 운영상의 필요를 충족합니다. 성공하면 행이 존재하지만 관리 대상 장치에는 계속 사용 불가능합니다. 필수 정보가 없으면 읽기 결과는notReady입니다. 누락된 열 인스턴스가 공급되면 에이전트는 행을notInService로 옮길 수 있습니다. 활성화를 시도할 만큼은 완전하지만 여전히 의도적으로 비활성인 상태입니다.

그 후 관리자가active를 씁니다. 에이전트는 전이를 수락하거나inconsistentValue로 거부할 수 있습니다. 완성은 현재 자원과 상태 하에서의 허용 가능성과 같지 않습니다.

에이전트는 이 협상된 경로를 지원하지 않아도 됩니다.createAndWait에wrongValue로 답하고 완전한 한 번 요청 생성을 요구할 수 있습니다. 상태 기계는 공통이지만, 지원되는 표면은 여전히 MIB와 에이전트가 정의합니다.

사용 불가능한 채로 남은 행은 자원을 소비합니다. 그래서 RFC 2579는 에이전트가 비정상적으로 오래notReady또는notInService로 남는 항목을 탐지하여 제거하도록 요구합니다. MIB 설명이 그 간격을 정의해야 하며, 정의하지 않으면 RFC는 사람의 사고 시간을 포함해 대략 5분을 제안합니다. 이는 제안된 기본값이지 어떤 벤더의 실제 타이머에 대한 증거가 아닙니다.

MIB 설명이 빠진 법을 담고 있었다

RowStatus가 모든 질문에 답하지는 않습니다. 어떤 테이블은 행이 active인 동안 열 변경을 허용합니다. 다른 테이블은 먼저 행을 서비스에서 제외하도록 요구합니다. 에이전트는 행이 사용 중이라는 이유로 정지를 거부할 수 있고, 같은 이유로 삭제도 거부할 수 있습니다.

상태 열의 DESCRIPTION은 활성화 전에 어떤 값이 요구되는지, 그리고 active인 동안 다른 열을 수정할 수 있는지 명시해야 합니다.RFC 4181은 이후 이를 명시적인 작성 의무로 만들었습니다. 동적이며 관리자가 만드는 테이블은 보통 read-create RowStatus 열을 하나 가져야 합니다. MIB는 또한 지속성, StorageType 동작, 에이전트 자신이 행을 만들거나 제거하는 조건, 그리고 정확한 수정 규칙을 설명해야 합니다.

이 textual convention은 모든 정책을 중앙화하지 않고 문법을 표준화합니다. 관리자에게 전이를 요청하는 공통 방법을 제공하면서, 각 MIB는 자신의 주제에 대해 유효한 행이 무엇인지 선언합니다.

하나의 SetRequest는 경계된 원자적 의미를 가졌다

생성은 종종 여러 열 값과 RowStatus 변경을 함께 보냅니다.RFC 3416은 SetRequest 처리를 개념적으로 두 단계로 정의합니다. 변수 바인딩을 검증한 다음, 검증이 성공하면 변경합니다. 할당은 그 요청 안의 다른 할당과 동시에 일어나는 것처럼 수행됩니다.

변경이 실패하면 그 엔티티는 다른 변경을 되돌리려 시도하고commitFailed를 반환합니다. 모든 것을 되돌릴 수 없으면undoFailed를 반환합니다. 후자의 코드가 존재한다는 것 자체가 "원자적"을 신화화하지 말라는 중요한 경고입니다.

그 보장은 하나의 SNMP 엔티티가 처리하는 하나의 요청에 국한됩니다. 여러 라우터에 걸친 트랜잭션이 아니고, 내구성 있는 커밋 프로토콜이 아니며, 분산 잠금도 아니고, 외부 데이터 플레인이 이제 의도대로 동작한다는 증명도 아닙니다. 성공 응답은 경계된 관리 사실을 확립할 뿐입니다. 재시작 후의 지속성과 기능적 효과는 별도의 증거를 요구합니다.

존재가 운영을 대신하는 척을 멈추다

RowStatus가 살아남은 이유는 테이블 문법보다 훨씬 큰 문제를 이름 지었기 때문입니다. 분산 구성은 여러 권한을 넘나듭니다. 관리자는 원하는 변경을 소유합니다. MIB는 공개 계약을 소유합니다. 에이전트는 표현하고 활성화할 수 있는 것을 검증합니다. 구동 중인 장치가 최종 운영 현실을 공급합니다.

이 계층들을 한데 뭉개면 오도하는 확신이 생깁니다. 보이는 행은 여전히notReady일 수 있습니다. 완전한 행은 여전히notInService일 수 있습니다. 활성화 요청은 여전히 실패할 수 있습니다.active값은 휘발성 저장소에만 남거나 트래픽이 흐른다는 증명이 아닐 수 있습니다. 각 관측은 더 많이 주장하지 않기에 정확히 유용합니다.

출처와 한계

RFC 1212와 RFC 1271은 RowStatus 이전의 관례와 RMON 선례를 확립합니다. RFC 1443과 RFC 2579는 여섯 값의 수명 주기를 정의합니다. RFC 3416은 SetRequest 처리를 정의하고, RFC 4181은 이후의 MIB 작성 관행을 기록합니다. 이 출처들은 현대 배포 점유율, 제품 적합성, 보안 정책, 하나의 보편적 정리 간격 또는 데이터 플레인 성공을 확립하지 않습니다. RowStatus를 의도, 준비 상태, 운영의 규율된 분리로 읽는 것은 이러한 메커니즘으로부터의 추론입니다.