요약

  • RowStatus는 읽을 수 있는 상태—active,notInService,notReady—와 쓰기 전용 동작—createAndGo,createAndWait,destroy—를 구분합니다. 매니저의 요청은 에이전트가 이후에 확인할 수 있는 조건으로 제시되지 않습니다.
  • createAndWait는 배타적인 예약을 하거나 활성화를 약속하지 않으면서도 불완전한 행을 가시적이고 복구 가능하게 만듭니다. 동시 할당과 롤백은 하나의 SetRequest 내에서 적용되며, 이후의 교환이나 여러 장치에 걸쳐 적용되지 않습니다.

자신의 증거가 될 수 없었던 동작

관리 애플리케이션이 새로운 필터, 측정 또는 정책 행을 만들려 한다고 가정해 보십시오. 인덱스와 일부 열은 알지만 모든 필수 값은 아닙니다.createAndWait를 쓰면 에이전트는 행을 서비스에 넣지 않은 채 개념적 행을 생성할 수 있습니다.

다음 읽기는 요청을 그대로 되돌려 주지 않습니다.RFC 2579는 서로 다른 역할을 가진 여섯 개의RowStatus값을 정의합니다.active와notInService는 읽거나 쓸 수 있는 상태입니다.notReady는 읽을 수는 있지만 쓸 수는 없는 상태입니다.createAndGo,createAndWait,destroy는 쓸 수 있지만 결코 읽을 수 없는 동작입니다.

불충분한 정보로 생성이 성공하면 에이전트는notReady를 보고합니다. 행을 관리 대상 장치에 제공하려 시도할 만큼의 정보가 있으면notInService를 보고합니다. 쓰여진 동작은 끝났고, 읽을 수 있는 상태는 남겨진 더 좁은 사실을 기술합니다.

이 구분은 두 가지 잘못된 결론을 막습니다.notReady행이 곧 실패한 생성은 아닙니다. 이미 인덱스, 열 인스턴스, 할당된 자원을 갖고 있을 수 있습니다.notInService행이 정당성을 인증받은 것도 아닙니다. 최종 활성화 결정이 아니라 정보 기준선을 넘었다는 뜻입니다.

에이전트가 단순히createAndWait를 반환했다면 인터페이스는 지시와 그 결과를 혼동했을 것입니다. 동작을 읽을 수 없게 만든 것으로 RowStatus는 매니저가 장치가 실제로 확립할 수 있는 것이 무엇인지 물어보게 했습니다.

작은 변수 모델이 행 모양의 프로세스를 만났다

1990년 5월RFC 1157에서 기술한 SNMP는 에이전트 기능을 이름 붙은 변수의 읽기와 변경으로 표현하도록 의도적으로 설계되었습니다. 이 설계는 장비 종류마다 고유한 명령형 명령의 목록이 늘어나는 것을 피했습니다.

개념적 행은 그 모델을 버리지 않으면서 복잡하게 만들었습니다. 행을 만들려면 충돌 없는 인덱스, 기본값이 없는 여러 열, 값들 간의 일관성, 희소 자원의 할당이 필요할 수 있습니다. 여러 관리 스테이션이 같은 제어 테이블을 사용할 수도 있습니다. 관리 대상 장치가 자체적으로 인스턴스를 만들 수도 있습니다.

변수를 설정할 수 있다는 것만으로 부분적 작업을 어떻게 노출할지, 다른 매니저가 어떻게 이어받을지, 시작한 주체가 사라지면 누가 자원을 회복할지 말해 주지 않았습니다. 행에는 부재와 서비스 사이의 생애가 필요했습니다.

원격 모니터링이 초기 운영 사례를 제공했습니다. 1991년 11월에 발표된RFC 1271은 여러 매니저가 모니터링 자원을 공유하는 RMON 제어 테이블을 기술했습니다. 그EntryStatus는createRequest,underCreation,valid,invalid를 사용했습니다. 주변 절차는 충돌, 실패한 매니저, 버려진 항목, 그리고 참여자가 누가 항목을 구성했는지 이해하도록 돕는 owner 문자열을 다루었습니다.

owner 문자열은 인증도 권한 부여도 아니었습니다. 권한이 아니라 맥락을 추가한 것입니다. 더 오래가는 조치는 생성이 시간을 차지하고, 다른 이가 관찰할 수 있고, 미완료로 남을 수 있음을 인정한 것이었습니다.

1993년 4월RFC 1443은 이 패턴을RowStatus텍스트 규약으로 일반화하면서 RMON의EntryStatus를 그 기원으로 명시했습니다.RFC 1903은 1996년에 이 규약을 개정했습니다. RFC 2579의 1999년 텍스트가 이 글에서 사용하는 상세한 수명 주기를 제공합니다. 한 계열의 제어 테이블에서 처음 구체화된 문제가 많은 MIB 모듈을 위한 재사용 가능한 인터페이스가 된 것입니다.

무엇이 부족한지 알기 위해 행을 만들기

createAndWait는 첫 단계에서 모든 필수 값을 제공할 수 없는 매니저를 지원합니다. 행이notReady로 읽히면 매니저는 그 열들을 검사할 수 있습니다. 아직 존재하지 않는 필수 인스턴스는noSuchInstance를 반환합니다. 매니저는 그 인스턴스들을 초기화할 수 있고, 필요한 정보가 갖추어지면 행은notInService가 됩니다.

따라서 부분적 진행은 시작한 클라이언트의 메모리에만 있지 않고 관리 인터페이스에 남습니다. 그 클라이언트가 재시작하더라도 운영자는 행을 읽을 수 있습니다. 두 번째 매니저는 부재와 불완전한 존재를 구분할 수 있습니다. 중간 상태가 공유 가능한 증거가 되는 것입니다.

notInService로의 이동은 여전히 구성을 검증하지 않습니다. 매니저가 나중에active를 쓸 때 에이전트는inconsistentValue로 전이를 거부할 수 있습니다. 모든 열이 존재하면서 그 조합 자체는 수용 불가능할 수 있습니다. 자원이 부족하거나 로컬 조건이 바뀌었을 수도 있습니다.

"활성화를 시도할 준비"는 "서비스를 위한 준비"보다 의도적으로 작은 서술입니다. 에이전트는 완전성과 수용 사이에 결정 경계를 유지합니다.

개별 객체 정의도 여전히 정책을 담고 있습니다. 그 DESCRIPTION 절은 행이 활성 상태에 있는 동안 열을 바꿀 수 있는지, 먼저 서비스에서 빠져 나와야 하는지, 에이전트가 일시 중지를 거부할 수 있는지를 지정할 수 있습니다. 한 테이블의 편집 동작을 RowStatus의 모든 사용에 투영해서는 안 됩니다.

기다리는 것이 행을 예약하지 않았다

불완전한 행은 그것을 만든 매니저가 소유한 예약처럼 보일 수 있습니다. RFC 2579는 그런 해석을 경고합니다.createAndWait를 쓰는 설정 작업과 나중에active를 쓰는 작업 사이에 관리 대상 장치는 자체 인스턴스를 만들 수 있습니다. 그러면 에이전트가 보유한 값이 매니저가 제공한 값을 대체할 수 있습니다.

다중 교환 수명 주기는 경쟁 창을 엽니다. 가시성은 잠금이 아닙니다. 첫 번째 쓰기 측은 생성 성공 응답을 받았다고 해서 인덱스에 대한 배타적 권리를 얻지 못합니다.

따라서 활성화 전에 결정적인 열을 다시 읽는 것은 중복된 절차가 아니라 동시성 확인입니다. 예상치 못한 변화는 대기 동안 다른 주체가 움직였다는 증거일 수 있습니다. 원래 값을 무조건 복원하는 재시도 루프는 그 충돌의 유일한 가시적 흔적을 지울 수 있습니다.

destroy도 같은 동작-상태 분리를 따릅니다. 행이active,notInService,notReady중 어느 것이든 요청할 수 있습니다. 작업이 성공하면 개념적 행에 속한 모든 인스턴스가 제거됩니다. 읽을 수 있는 상태가 destroy인 행은 남지 않습니다. 부재가 그 동작의 결과입니다.

운영자가 과거 삭제 기록이 필요하다면 요청, 이전 읽기 값, 승인을 감사 시스템에 보관해야 합니다. RowStatus는 현재 수명 주기를 기술합니다. 이벤트 대장이 아닙니다.

에이전트는 영원히 기다릴 수 없었다

단계적 생성은 복구를 가능하게 하지만 방임도 허용합니다. 매니저 프로세스는 생성 후 충돌할 수 있습니다. 네트워크가 실패할 수 있습니다. 운영자가 작업을 내려놓을 수 있습니다. 행은 장치에 사용 가능하지 않으면서도 메모리, 테이블 슬롯 또는 모니터링 자원을 계속 소비합니다.

RFC 2579는 정리를 에이전트에 맡깁니다. 에이전트는 비정상적으로 오래notReady또는notInService에 머문 개념적 행을 탐지해 제거해야 합니다. 그 기간을 정의하는 것은 상태 열의 DESCRIPTION 책임입니다. 그것이 정의하지 않을 때에만 RFC는 약 5분을 제안합니다.

따라서 5분은 보편적인 타임아웃이 아닙니다. 희소 자원은 더 빠른 회복을 정당화할 수 있습니다. 외부 승인을 기다리는 정당한 워크플로는 더 긴 시간이 필요할 수 있습니다. 그 기간은 테이블을 두고 경쟁하는 사용자들에게 용량과 회복 기회를 배분합니다.

정리 규칙은 서비스에서 너무 오래 빠져 있던 이전에 활성이던 행에도 적용됩니다. 새 생성 시도에만 국한되지 않습니다. 기대 기간을 넘어 자원을 점유하는 모든 중간 상태는 회복 의무를 만듭니다.

에이전트는 로컬 자원을 보유하므로 최후의 정리 수단을 소유합니다. 그러나 사라진 매니저의 의도는 알지 못합니다. 객체 정의는 가정된 구현 기본값 뒤에 숨기지 말고 그 절충을 명시해야 합니다.

하나의 요청은 수명 주기보다 강한 경계를 가졌다

SNMP의 쓰기 절차는 임의의 열 변경의 나열보다 강합니다.RFC 3416은 에이전트가 할당 전에 SetRequest의 변수 바인딩을 검증하도록 요구합니다. 같은 요청 안의 할당은 서로에 대해 동시에 일어나는 것처럼 처리됩니다. 하나의 할당이 실패하면 나머지는 취소되고 응답은commitFailed를 보고합니다. 모든 할당을 취소할 수 없으면undoFailed를 보고합니다.

이것은 유용하고 정확한 경계입니다. 매니저는 여러 열과 생성 동작을 하나의 PDU에 담아 그 요청에 대한 공통 처리를 얻을 수 있습니다.

그러나 이것이createAndWait, 이후의 읽기, 추가 열 쓰기, 활성화의 나열을 하나의 트랜잭션으로 감싸지는 않습니다. 각 응답은 자신의 요청을 완결합니다. 다음 교환 전에 연결 끊김, 경쟁 쓰기 또는 장치 측 변경이 일어날 수 있습니다. 나중의 SetRequest의 롤백은 이전에 완료된 교환들을 거슬러 올라가지 않습니다.

이 규칙은 여러 에이전트를 조율하지도 않습니다. "동시에 일어나는 것처럼"은 하나의 응답 개체가 처리하는 하나의 요청 안의 할당들을 비교합니다. 라우터, 모니터 또는 다른 장치에 걸친 분산 커밋을 만들지 않습니다.

undoFailed라는 이름조차 필요한 한계를 보존합니다. 롤백 자체를 완료할 수 없을 때 매니저는 유효 상태를 읽고 관찰로부터 회복해야 합니다. "아무것도 바뀌지 않았다"고 기록하는 것은 에이전트가 보증할 수 없는 것을 정확히 단언하는 셈입니다.

한정된 주장들의 수명 주기

RowStatus는 복합 구성이 동작할 것을 보증하지 않았습니다. 더 좁은 책임들을 배분했습니다. 매니저는 생성을 요청하고, 값을 제공하고, 활성화를 요청할 시점을 선택합니다. 에이전트는 인스턴스를 만들 수 있는지, 정보가 충분한지, 값이 일관되는지, 자원이 있는지, 방임된 작업을 언제 제거할지를 결정합니다. 테이블 정의는 그 편집 및 만료 정책을 제공합니다.

그 분할은 서로 다른 주장들의 연쇄를 만듭니다: 동작이 전송되었다; 생성이 수용되었다; 행이 존재한다; 필요한 정보가 있다; 에이전트가active를 수용했다; 의도한 서비스 효과가 발생했다. 어느 것도 다음을 자동으로 증명하지 않습니다.

준비되기 전에 존재했던 행은 부끄러운 구현 누설이 아니었습니다. 그것은 프로세스의 중간을 표준화한 표현이었습니다. SNMP는 복합 구성이 하나의 순간적 변수인 것처럼 꾸미는 대신, 한정된 수명 주기를 노출함으로써 자신의 연산을 작게 유지했습니다.

출처