신뢰할 수 있는 서버 풀링

Reliable Server Pooling

RSERPool(신뢰할 수 있는 서버 풀링)은 여러 개의 조정된 (풀링된) 서버를 관리하고 액세스하기 위한 컴퓨터 프로토콜 프레임워크다.RSerPool은 IETF RSerPool 작업 그룹에[1] 의해 개발되었으며 RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 및 RFC 5356에 문서화되었다.

소개

RSerPool의 용어에서 서버는 PE(Pool Element)로 표시된다.풀에서 32비트 번호인 PE ID(Pool Element Identifier)로 식별된다.PE ID는 PE가 해당 풀에 등록할 때 무작위로 선택된다.모든 풀의 세트는 핸들스페이스로 표시된다.구 문헌에서는 네임스페이스로 표기할 수 있다.이 교단은 DNS(Domain Name System)와의 혼동을 피하기 위해 삭제되었다.핸들스페이스의 각 풀은 임의 바이트 벡터로 표현되는 고유한 풀 핸들(PH)로 식별된다.일반적으로 이것은 풀의 ASCII 또는 유니코드 이름(예: "DownloadPool" 또는 "WebServerPool")이다.

각 핸들스페이스에는 운영 범위(예: 조직 또는 회사)로 표시된 특정 범위가 있다.RSerPool의 목표는 글로벌 인터넷 풀을 단일 핸들 공간 내에서 관리하는 것이 아니다.Operation Scope의 국소화 때문에 핸들 공간을 "평평한" 상태로 유지할 수 있다.즉, PHs는 최상위 수준과 하위 도메인을 가진 도메인 네임 시스템과 대조적으로 어떠한 계층 구조도 가지고 있지 않다.이러한 제약으로 인해 핸들 스페이스 관리가 상당히 단순화된다.

운영 범위 내에서 핸들스페이스는 ENRP 서버 또는 Name Servers(NS)로 표시되는 중복 풀 등록자(PR)에 의해 관리된다. PR이 단일 장애 지점(SpoF)이 되지 않기 위해서는 PR이 중복되어야 한다.운영 범위의 각 PR은 32비트 무작위 번호인 등록자 ID(PR ID)로 식별된다.PR ID의 고유성을 보장할 필요는 없다. PR에는 운영 범위의 핸들 스페이스 전체 사본이 포함되어 있다.운영 범위의 PR은 Endpoint Handspace Dynamation Protocol(ENRP)을 사용하여 핸들 공간에 대한 보기를 동기화한다.이 프로토콜의 이전 버전에서는 Endpoint 네임스페이스 이중화 프로토콜이라는 용어를 사용한다. 이 이름은 DNS와의 혼동을 피하기 위해 대체되었지만 약어는 유지되었다.ENRP에 의한 핸들스페이스 동기화로 인해 운용범위의 PR은 기능적으로 동일하다.즉, PR 중 하나라도 실패하면 서로 PR이 이를 원활하게 대체할 수 있다.

PE는 ASAP(Agggregate Server Access Protocol)를 사용하여 자신을 풀에 추가하거나 운영 범위의 임의 PR에 등록 또는 등록을 취소하여 풀에서 제거할 수 있다.등록에 성공하면 등록 대상으로 선정된 PR이 PE의 홈-PR(PR-H)이 된다.PR-H는 PE의 등록 또는 등록 해제에 대한 운영 범위를 다른 PR에게 알릴 뿐만 아니라, ASAP Keep-Alive 메시지를 통해 PE의 가용성을 모니터링한다.PR-H에 의한 keep-alive 메시지는 특정 시간 간격 내에 PE에 의해 승인되어야 한다.PE가 특정 시간 제한 내에 응답하지 못할 경우, PE는 사망한 것으로 가정하고 핸들 공간에서 즉시 제거된다.게다가, PE는 정기적으로 재등록될 것으로 예상된다.재등록 시 PE의 전송 주소 목록이나 정책 정보도 변경할 수 있다.

풀 서비스를 사용하려면 RSerPool 용어로 PU(Pool User)라고 하는 클라이언트가 먼저 운영 범위의 임의 PR에서 PE ID 목록에 풀의 PH의 확인을 요청해야 한다.이 선택 절차는 Handle Resolution(Handle Resolution).요청된 풀이 존재하는 경우 PR은 풀의 Pool 멤버 선택 정책에 따라 PE ID 목록을 선택하는데, PR은 Pool Policy라고도 한다.

가능한 풀 정책은 예를 들어 임의 선택(랜덤) 또는 최소 부하 PE(최소 사용)이다.첫 번째 경우에는 선택 정보를 가질 필요가 없지만(PE는 무작위로 선택), 두 번째 최소 부하 PE를 선택하는 경우에는 최신 부하 정보를 유지해야 한다.적절한 선택 정책을 사용하면 요청 로드를 풀의 PE에 균등하게 분배할 수 있다.

PR에서 PE ID 목록을 수신한 후 PU는 PE 정보를 로컬 캐시에 기록한다.이 캐시는 PU측 캐시라고 한다.그것의 캐시에서, PU는 정확히 하나의 PE (다시 한번 풀의 선택 정책을 사용하여)를 선택하고, 웹 서버의 경우 응용 프로그램의 프로토콜(예: SCTP를 통한 HTTP 또는 TCP)을 사용하여 PE에 대한 연결을 설정할 것이다.이 연결을 사용하여 서버에서 제공하는 서비스가 사용된다.서비스 사용 중 연결 설정이 실패하거나 연결이 중단된 경우, 기술된 선택 절차를 반복하여 새로운 PE를 선택할 수 있다.PU측 캐시의 정보가 오래되지 않은 경우, PR에 핸들 해결을 요청하는 노력을 건너뛰고 캐시에서 PE ID를 직접 선택할 수 있다.새로운 PE와의 연결을 다시 설정한 후에는 새로운 PE에 대해 응용 세션의 상태를 다시 인스턴스화해야 한다.세션 재개를 위해 필요한 절차는 장애 조치 절차로 표시되며, 물론 애플리케이션별로 다르다.예를 들어 FTP 다운로드의 경우, 오류 해결 절차는 새 FTP 서버에 파일 이름과 마지막으로 수신된 데이터 위치를 알려주는 것을 의미할 수 있다.그것에 의해, FTP 서버는 다운로드 세션을 재개할 수 있을 것이다.RSerPool은 Session Layer 메커니즘에 의해 임의 페일오버 시스템의 구현에 대한 광범위한 지원을 제공하지만 페일오버 절차는 애플리케이션 의존성이 높기 때문에 RSerPool 자체의 일부가 아니다.

RSerPool 구성요소가 자동으로 구성될 수 있도록 PR은 UDP over IP 멀티캐스트를 통해 자신을 알릴 수 있다.이러한 공지사항은 PE, PU 및 기타 PR이 접수할 수 있어 운영 범위에서 현재 이용 가능한 PR 목록을 학습할 수 있다.브로드캐스트 대신 IP 멀티캐스트를 사용하는 이점은 이 메커니즘이 라우터(예: VPN을 통해 상호 연결된 LAN)에서도 작동하고, 발표 의지(예: 교환 이더넷)는 이 정보에 실제로 관심이 있는 방송국에 의해서만 듣고 처리된다는 것이다.IP 멀티캐스트를 사용할 수 없는 경우, 물론 PR 주소를 정적으로 구성하는 것이 가능하다.

구현

다음과 같은 구현이 알려져 있다.

표준 문서

RFCs

  • RFC 3237 - 신뢰할 수 있는 서버 풀링 요구 사항
  • RFC 5351 - 신뢰할 수 있는 서버 풀링 프로토콜 개요
  • RFC 5352 - Aggregate Server Access Protocol(ASAP)
  • RFC 5353 - Endpoint 핸들스페이스 이중화 프로토콜(ENRP)
  • RFC 5354 - ASAP(Agggregate Server Access Protocol) 및 EnRP(Endpoint Handspace Dedundancy Protocol) 매개변수
  • RFC 5355 - 신뢰할 수 있는 서버 풀링(RSERPool)에 의해 도입된 위협 및 위협에 대한 보안 요구 사항
  • RFC 5356 - 신뢰할 수 있는 서버 풀링 정책
  • RFC 5525 - 신뢰할 수 있는 서버 풀링 MIB 모듈 정의

작업 그룹 초안

기타 초안

참조

  1. ^ RSerPool

외부 링크