Orleans의 클러스터 관리

  • 아티클

Orleans는 기본 제공 멤버 자격 프로토콜을 통해 클러스터 관리를 제공합니다. 이를 사일로 멤버 자격이라고도 합니다. 이 프로토콜의 목표는 모든 사일로(Orleans 서버)가 현재 활성 사일로 세트에 동의하고, 실패한 사일로를 검색하고, 새 사일로가 클러스터에 조인될 수 있도록 하는 것입니다.

프로토콜은 외부 서비스를 사용하여 IMembershipTable의 추상화를 제공합니다. IMembershipTable은 두 가지 용도로 사용하는 플랫 No-SQL과 유사한 지속성 테이블입니다. 첫째, 사일로가 서로를 찾고, Orleans 클라이언트가 사일로를 찾는 랑데부 지점으로 사용됩니다. 둘째, 현재 멤버 자격 보기(활성 사일로 목록)를 저장하고 멤버 자격 보기에 대한 규약을 조정하는 데 사용됩니다. 현재 Azure Table Storage, SQL Server, Apache ZooKeeper, Consul IO, AWS DynamoDB 및 개발용 메모리 내 에뮬레이션을 기반으로 하는 IMembershipTable의 6가지 구현이 있습니다.

IMembershipTable 외에도 각 사일로는 실패한 사일로를 감지하고 활성 사일로 세트에 대한 합의에 도달하는 완전히 분산된 피어 투 피어 멤버 자격 프로토콜에 참여합니다. 먼저 Orleans의 멤버 자격 프로토콜의 내부 구현을 설명하고 나중에 IMembershipTable의 구현에 대해 설명합니다.

기본 멤버 자격 프로토콜

  1. 시작 시 모든 사일로는 IMembershipTable 구현을 사용하여 잘 알려진 공유 테이블에 자체 항목을 추가합니다. 사일로 ID(ip:port:epoch)와 서비스 배포 ID의 조합은 테이블에서 고유 키로 사용됩니다. Epoch는 이 사일로가 시작된 틱 단위의 시간이므로 ip:port:epoch는 지정된 Orleans 배포에서 고유함이 보장됩니다.

  2. 사일로는 애플리케이션 ping("활성화" heartbeats)을 통해 서로를 직접 모니터링합니다. Ping은 사일로가 통신하는 동일한 TCP 소켓을 통해 사일로 간 직접 메시지로 전송됩니다. 이러한 방식으로 ping은 실제 네트워킹 문제 및 서버 상태와 완전히 상관 관계가 있습니다. 모든 사일로는 구성 가능한 다른 사일로 집합을 ping합니다. 사일로는 다른 사일로의 ID에 대한 일관된 해시를 계산하고, 모든 ID의 가상 링을 형성하고, 링에서 X개의 후속 사일로를 선택하여 ping할 사용자를 선택합니다(이는 일관된 해시라고 하는 잘 알려진 분산 기술이며 Chord DHT와 같은 많은 분산 해시 테이블에서 널리 사용됨).

  3. 사일로 S가 모니터링되는 서버 P에서 Y ping 응답을 받지 못하면 타임스탬프가 있는 주의 대상을 IMembershipTable의 P 행에 기록하여 주의합니다.

  4. P가 K초 내에 Z 주의 대상을 초과하는 경우 S는 P가 P의 행에 종료되었음을 기록하고 모든 사일로가 멤버 자격 테이블을 다시 읽도록 요청을 브로드캐스트합니다(어쨌든 정기적으로 수행됨).

  5. 자세한 정보:

    1. 주의 대상은 P에 해당하는 행의 특수 열에 있는 IMembershipTable에 기록됩니다. S가 P를 주의할 때 "TTT S가 P를 주의한 시점"을 씁니다.

    2. 하나의 주의 대상은 P를 종료로 선언하기에 충분하지 않습니다. P를 종료로 선언하려면 구성 가능한 시간 창 T(일반적으로 3분)에 다른 사일로의 Z 주의 대상이 필요합니다. 주의 대상은 IMembershipTable에서 제공하는 낙관적 동시성 제어를 사용하여 작성됩니다.

    3. 의심스러운 사일로 S는 P의 행을 읽습니다.

    4. S가 마지막 용의자인 경우(주의 대상 열에 기록된 대로 T 기간 내에 이미 Z-1 용의자가 있음) S는 P를 종료로 선언하기로 결정합니다. 이 경우 S는 용의자 목록에 자신을 추가하고 P의 상태 열에 P가 종료했다고 기록합니다.

    5. 그렇지 않으면 S가 마지막 용의자가 아닌 경우 S는 용의자의 열에 자신을 추가합니다.

    6. 두 경우 모두 쓰기 저장은 읽은 버전 번호 또는 ETag를 사용하므로 이 행에 대한 업데이트가 직렬화됩니다. 버전/ETag 불일치로 인해 쓰기가 실패한 경우 S는 다시 시도합니다(P가 이미 종료된 것으로 표시되지 않는 한 다시 읽고 쓰기를 시도함).

    7. 높은 수준에서 "읽기, 로컬 수정, 쓰기 저장"의 이 시퀀스는 트랜잭션입니다. 그러나 이를 위해 스토리지 트랜잭션을 사용하지는 않습니다. "트랜잭션" 코드는 서버에서 로컬로 실행되며 격리 및 원자성을 보장하기 위해 IMembershipTable에서 제공하는 낙관적 동시성을 사용합니다.

  6. 모든 사일로는 배포에 대한 전체 멤버 자격 테이블을 주기적으로 읽습니다. 이러한 방식으로 사일로가 새로운 사일로 조인과 다른 사일로가 종료된 것으로 선언되는 것에 대해 알아봅니다.

  7. 구성: Azure에서 프로덕션을 사용하는 동안 직접 조정된 기본 구성을 제공합니다. 현재 기본값은 모든 사일로가 3개의 다른 사일로에 의해 모니터링되고, 2개의 주의 대상은 사일로 종료를 선언하기에 충분하며, 마지막 3분 동안만 주의합니다(그렇지 않으면 구식임). Ping은 10초마다 전송되며 사일로를 주의하려면 세 개의 ping을 놓쳐야 합니다.

  8. 완벽한 실패 감지 적용 – 이론적으로 사일로 프로세스 자체가 여전히 실행 중인 동안 다른 사일로와의 통신이 끊어지면 사일로가 종료된 것으로 선언될 수 있습니다. 이 문제를 해결하려면 테이블에서 사일로가 종료로 선언되면 사일로가 종료되지 않았더라도(일시적으로 분할되거나 하트비트 메시지가 손실된 경우) 모두 종료된 것으로 간주됩니다. 모두가 통신을 중지하고 테이블에서 새로운 상태를 읽음으로써 중단된 것을 알게 되면 해당 프로세스를 종료합니다. 따라서 새 프로세스로 사일로를 다시 시작하는 인프라가 있어야 합니다(시작 시 새 epoch 번호가 생성됨). Azure에서 호스트되면 자동으로 발생합니다. 그렇지 않은 경우 다른 인프라가 필요합니다. 예를 들어 실패 또는 Kubernetes 배포 시 자동으로 다시 시작하도록 구성된 Windows 서비스입니다.

  9. 주기적 테이블 읽기 빈도를 줄이고 새로운 조인 사일로 및 데드 사일로에 대해 학습하는 모든 사일로의 속도를 높이는 최적화. 모든 사일로가 테이블에 성공적으로 기록될 때마다(주의 대상, 새 조인 등) 다른 모든 사일로에도 브로드캐스트됩니다. 즉, "지금 바로 테이블을 다시 읽어 보세요". 사일로는 테이블에 쓴 내용을 다른 사람에게 알리지 않고(이 정보는 이미 오래되었거나 잘못될 수 있으므로) 테이블을 다시 읽도록 지시하기만 하면 됩니다. 이렇게 하면 전체 정기적인 읽기 주기를 기다릴 필요 없이 멤버 자격 변경에 대해 매우 빠르게 학습할 수 있습니다. "테이블 다시 읽기" 메시지가 손실되는 경우를 대비하여 주기적인 읽기가 필요합니다.

기본 멤버 자격 프로토콜의 속성

  1. 여러 오류를 처리할 수 있습니다.

    알고리즘은 전체 클러스터 다시 시작을 포함하여 많은 오류(즉, f<=n)를 처리할 수 있습니다. 이는 일반적으로 대부분의 쿼럼이 필요한 "기존" Paxos 기반 솔루션과는 대조적입니다. 생산 상황에서 사일로의 절반 이상이 다운된 것을 볼 수 있습니다. Paxos 기반 멤버 자격이 진행되지 않는 동안 시스템은 계속 작동했습니다.

  2. 테이블로의 트래픽은 매우 적습니다.

    실제 ping은 테이블이 아닌 서버 간에 직접 이동합니다. 이렇게 하면 많은 트래픽을 생성하고 실패 감지 관점에서 정확도가 떨어질 수 있습니다. 사일로가 테이블에 도달할 수 없는 경우 활성화된 하트 비트를 작성하지 못하고, 다른 사용자가 종료할 것입니다.

  3. 튜닝 가능한 정확도 및 완전성:

    완벽하고 정확한 오류 감지를 모두 달성할 수는 없지만, 일반적으로 정확성(라이브 사일로를 종료로 선언하고 싶지 않음)과 완전성(종료된 사일로를 최대한 빨리 종료로 선언하기를 원함)을 절충하는 기능을 원합니다. 데드 및 놓친 핑을 선언하는 구성 가능한 투표를 통해 이 두 가지를 거래할 수 있습니다. 자세한 내용은 예일 대학교: 컴퓨터 과학 오류 감지기를 참조하세요.

  4. 스케일링:

    기본 프로토콜은 수천에서 수만 대의 서버를 처리할 수 있습니다. 이는 수십 개 이상으로 확장되지 않는 것으로 알려진 그룹 통신 프로토콜과 같은 기존 Paxos 기반 솔루션과는 대조적입니다.

  5. 진단:

    이 테이블은 진단 및 문제 해결에도 매우 편리합니다. 시스템 관리자는 테이블에서 활성 사일로의 현재 목록을 즉시 찾을 수 있으며 종료된 모든 사일로 및 주의 대상의 역사를 볼 수 있습니다. 이는 문제를 진단할 때 특히 유용합니다.

  6. 구현을 위해 안정적인 영구 스토리지가 필요한 이유는 다음과 같습니다IMembershipTable.

    두 가지 목적을 위해 IMembershipTable에 영구 스토리지(Azure 테이블, SQL Server, AWS DynamoDB, Apache ZooKeeper 또는 Consul IO KV)를 사용합니다. 첫째, 사일로가 서로를 찾고, Orleans 클라이언트가 사일로를 찾는 랑데부 지점으로 사용됩니다. 둘째, 신뢰할 수 있는 스토리지를 사용하여 멤버 자격 보기에 대한 규약을 조정할 수 있습니다. 사일로 간에 피어 투 피어 방식으로 직접 오류 감지를 수행하는 동안 멤버 자격 보기를 신뢰할 수 있는 스토리지에 저장하고 이 스토리지에서 제공하는 동시성 제어 메커니즘을 사용하여 누가 활성화되어 있고 누가 종료되었는지에 대한 합의에 도달합니다. 이러한 방식으로 프로토콜은 분산 합의라는 어려운 문제를 클라우드에 아웃소싱합니다. 기본 클라우드 플랫폼의 기능을 완전히 활용하고, 이를 실제로 PaaS(Platform as a Service)로 사용합니다.

  7. 일정 시간 동안 테이블에 액세스할 수 없으면 어떻게 되나요?

    스토리지 서비스가 다운되거나 사용할 수 없거나 통신 문제가 있는 경우 Orleans 프로토콜은 실수로 사일로를 중단된 것으로 선언하지 않습니다. 운영 사일로는 아무런 문제 없이 계속 작동합니다. 그러나 Orleans는 사일로 중단을 선언할 수 없으며(누락된 ping을 통해 일부 사일로가 중단된 것을 검색하면 이 팩트를 테이블에 쓸 수 없음), 새로운 사일로의 조인을 허용할 수도 없습니다. 따라서 완전성은 저하되지만 정확도는 그렇지 않습니다. 테이블에서 분할해도 Orleans가 실수로 사일로를 종료한 것으로 선언하는 일이 발생하지 않습니다. 또한 부분 네트워크 파티션의 경우(일부 사일로가 테이블에 액세스할 수 있고 일부는 액세스할 수 없는 경우) Orleans가 데드 사일로를 종료로 선언할 수 있지만 다른 모든 사일로가 이에 대해 알게 될 때까지 약간의 시간이 걸릴 수 있습니다. 따라서 검색이 지연될 수 있지만 Orleans는 테이블을 사용할 수 없어서 사일로를 잘못 종료하지 않습니다.

  8. Direct IAmAlive는 진단용으로만 테이블에 씁니다.

    사일로 간에 전송되는 하트비트 외에도 각 사일로는 테이블의 행에 있는 "I Am Alive" 열을 주기적으로 업데이트합니다. 이 "I Am Alive" 열은 수동 문제 해결 및 진단에만 사용되며 멤버 자격 프로토콜 자체에서는 사용되지 않습니다. 일반적으로 훨씬 낮은 빈도(5분마다 한 번씩)로 작성되며 시스템 관리자가 클러스터의 활성 상태를 확인하거나 사일로가 마지막으로 활성 상태인 시기를 쉽게 파악할 수 있는 매우 유용한 도구로 사용됩니다.

멤버 자격 보기를 정렬하는 확장

위에서 설명한 기본 멤버 자격 프로토콜은 나중에 정렬된 멤버 자격 보기를 지원하도록 확장되었습니다. 이 확장의 이유와 구현 방법을 간략하게 설명합니다. 확장은 위의 디자인에서 아무것도 변경하지 않고 모든 멤버 자격 구성이 전역적으로 완전히 정렬되는 속성을 추가합니다.

멤버 자격 보기를 정렬하는 것이 유용한 이유는 무엇인가요?

  • 이렇게 하면 클러스터에 새 사일로의 조인을 직렬화할 수 있습니다. 이를 통해 새 사일로가 클러스터에 조인되면 이미 시작된 다른 모든 사일로에 대한 양방향 연결의 유효성을 검사할 수 있습니다. 이미 조인된 사일로 중 일부가 응답하지 않는 경우(새 사일로의 네트워크 연결 문제를 잠재적으로 나타냄) 새 사일로는 조인할 수 없습니다. 이렇게 하면 적어도 사일로가 시작될 때 클러스터의 모든 사일로 간에 전체 연결이 유지됩니다(구현됨).

  • 분산된 조직 디렉터리와 같은 사일로의 상위 수준 프로토콜은 멤버 자격 보기가 정렬된다는 사실을 활용하고 이 정보를 사용하여 보다 스마트한 중복 정품 인증 확인을 수행할 수 있습니다. 특히 디렉터리가 멤버 자격이 유동적일 때 2개의 정품 인증이 생성되었음을 알게 되면, 현재 오래된 멤버 자격 정보를 기반으로 만든 이전 정품 인증을 비활성화하기로 결정할 수 있습니다.

확장 멤버 자격 프로토콜:

  1. 이 기능을 구현하기 위해 MembershipTable에서 제공하는 여러 행에 대한 트랜잭션에 지원을 활용합니다.

  2. 테이블 변경 내용을 추적하는 테이블에 멤버 자격 버전 행을 추가합니다.

  3. 사일로 S가 사일로 P에 대한 주의 대상 또는 종료 선언을 작성하려는 경우:

    1. S는 최신 테이블 콘텐츠를 읽습니다. P가 이미 종료된 경우 아무 것도 하지 않습니다. 그렇지 않으면
    2. 동일한 트랜잭션에서 P의 행에 변경 내용을 작성하고 버전 번호를 증가시키고 테이블에 다시 씁니다.
    3. 두 쓰기 모두 ETag로 조건이 지정됩니다.
    4. P의 행 또는 버전 행에서 ETag 불일치로 인해 트랜잭션이 종료되는 경우 다시 시도합니다.

  4. 테이블에 대한 모든 쓰기는 버전 행을 수정하고 증가시킵니다. 이렇게 하면 테이블에 대한 모든 쓰기가 직렬화되고(버전 행에 대한 업데이트 직렬화를 통해) 사일로가 버전 번호만 증가하므로 쓰기도 오름차순으로 정렬됩니다.

확장 멤버 자격 프로토콜의 확장성:

프로토콜의 확장 버전에서 모든 쓰기는 하나의 행을 통해 직렬화됩니다. 이렇게 하면 동시 테이블 쓰기 간의 충돌 위험이 증가하므로 클러스터 관리 프로토콜의 확장성이 저하될 수 있습니다. 이 문제를 부분적으로 완화하기 위해 사일로는 지수 백오프를 사용하여 테이블에 대한 모든 쓰기를 다시 시도합니다. 최대 200개 사일로가 있는 Azure의 프로덕션 환경에서 원활하게 작동하도록 확장된 프로토콜을 관찰했습니다. 그러나 프로토콜이 수천 개의 사일로를 초과하는 크기 조정에 문제가 있을 수 있다고 생각합니다. 이러한 대규모 설정에서는 버전 행에 대한 업데이트를 쉽게 비활성화될 수 있으며, 기본적으로 클러스터 관리 프로토콜의 나머지 부분을 유지 관리하고 총 순서 지정 속성을 포기할 수 있습니다. 또한 여기에서는 나머지 Orleans가 아닌 클러스터 관리 프로토콜의 확장성을 참조하세요. Orleans 런타임의 다른 부분(메시징, 분산 디렉터리, 조직 호스팅, 클라이언트-게이트웨이 연결)은 수백 개의 사일로를 넘어 확장 가능한 방식이라고 생각합니다.

멤버 자격 테이블

이미 언급했듯이 IMembershipTable은 사일로가 사일로를 찾을 수 있는 랑데부 지점으로 사용되고 있으며, 사일로를 찾을 수 있는 Orleans 클라이언트를 찾고 멤버 자격 보기에 대한 규약을 조정하는 데도 도움이 됩니다. 현재 Azure Table, SQL Server, Apache ZooKeeper, Consul IO, AWS DynamoDB 및 개발용 메모리 내 에뮬레이션을 기반으로 하는 IMembershipTable의 6가지 구현이 있습니다.

  1. Azure Table Storage - 이 구현에서는 Azure 배포 ID를 파티션 키로 사용하고, 사일로 ID(ip:port:epoch)를 행 키로 사용합니다. 함께 사일로당 고유한 키를 보장합니다. 동시성 제어의 경우 Azure Table ETags를 기반으로 낙관적 동시성 제어를 사용합니다. 테이블에서 읽을 때마다 모든 읽기 행에 대한 ETag를 저장하고 쓰기 저장하려고 할 때 해당 ETag를 사용합니다. ETag는 모든 쓰기에 대해 Azure Table Service에서 자동으로 할당되고 확인됩니다. 다중 행 트랜잭션의 경우 Azure 테이블에서 제공하는 일괄 처리 트랜잭션에 대한 지원을 활용하여 동일한 파티션 키가 있는 행을 통해 직렬화 가능한 트랜잭션을 보장합니다.

  2. SQL Server - 이 구현에서 구성된 배포 ID는 배포와 배포에 속하는 사일로를 구분하는 데 사용됩니다. 사일로 ID는 적절한 테이블과 열에서 deploymentID, ip, port, epoch의 조합으로 정의됩니다. 관계형 백 엔드는 Azure Table 구현에서 ETag를 사용하는 절차와 유사하게 낙관적 동시성 제어 및 트랜잭션을 사용합니다. 관계형 구현에서는 데이터베이스 엔진이 사용된 ETag를 생성해야 합니다. SQL Server의 경우 SQL Server 2000에서 생성된 ETag는 NEWID() 호출에서 얻은 것입니다. SQL Server 2005 이상에서는 ROWVERSION이 사용됩니다. Orleans는 관계형 ETag를 불투명 VARBINARY(16) 태그로 읽고 쓰고 base64로 인코딩된 문자열로 메모리에 저장합니다. Orleans는 현재 통계 데이터를 삽입하는 데 사용되는 UNION ALL(DUAL을 포함한 Oracle의 경우)를 사용하여 다중 행 삽입을 지원합니다. SQL Server의 정확한 구현과 이론적 근거는 CreateOrleansTables_SqlServer.sql에서 확인할 수 있습니다.

  3. Apache ZooKeeper - 이 구현에서는 구성된 배포 ID를 루트 노드로 사용하고 자식 노드로 사일로 ID(ip:port@epoch)를 사용합니다. 함께 사일로당 고유한 경로를 보장합니다. 동시성 제어의 경우 노드 버전을 기반으로 낙관적 동시성 제어를 사용합니다. 배포 루트 노드에서 읽을 때마다 모든 읽기 자식 사일로 노드에 대한 버전을 저장하고 다시 쓰려고 할 때 해당 버전을 사용합니다. 노드의 데이터가 변경될 때마다 버전 번호는 ZooKeeper 서비스에 의해 원자성으로 증가합니다. 다중 행 트랜잭션의 경우 동일한 부모 배포 ID 노드가 있는 사일로 노드를 통해 직렬화 가능한 트랜잭션을 보장하는 다중 메서드를 활용합니다.

  4. Consul IO - Consul의 키/값 저장소를 사용하여 멤버 자격 테이블을 구현했습니다. 자세한 내용은 Consul-Deployment를 참조하세요.

  5. AWS DynamoDB - 이 구현에서는 클러스터 배포 ID를 파티션 키로 사용하고 사일로 ID(ip-port-generation)를 RangeKey로 사용하여 레코드 통합을 만듭니다. 낙관적 동시성은 DynamoDB에서 조건부 쓰기를 수행하여 ETag 특성에 의해 이루어집니다. 구현 논리는 Azure Table Storage와 매우 유사합니다.

  6. 개발 설정을 위한 메모리 내 에뮬레이션입니다. 해당 구현을 위해 MembershipTableGrain이라는 특수 시스템 조직을 사용합니다. 이 조직은 개발 설정에만 사용되는 지정된 기본 사일로에 있습니다. 실제 프로덕션 사용 시 기본 사일로는 필요하지 않습니다.

구성

멤버 자격 프로토콜은 OrleansConfiguration.xml 파일의 Globals 섹션에 있는 Liveness 요소를 통해 구성됩니다. 기본값은 Azure에서 수년간의 프로덕션 사용량으로 조정되었으며, 이는 적절한 기본 설정을 나타낸다고 생각합니다. 일반적으로 변경할 필요가 없습니다.

샘플 구성 요소:

<Liveness ProbeTimeout="5s"
    TableRefreshTimeout="10s"
    DeathVoteExpirationTimeout="80s"
    NumMissedProbesLimit="3"
    NumProbedSilos="3"
    NumVotesForDeathDeclaration="2" />

구현된 4가지 활동성 유형이 있습니다. 활성 프로토콜 형식은 OrleansConfiguration.xml 파일의 Globals 섹션에 있는 SystemStore 요소의 SystemStoreType 특성을 통해 구성됩니다.

  1. MembershipTableGrain: 멤버 자격 테이블은 기본 사일로의 조직에 저장됩니다. 이는 개발 설정 전용입니다.
  2. AzureTable: 멤버 자격 테이블은 Azure 테이블에 저장됩니다.
  3. SqlServer: 멤버 자격 테이블은 관계형 데이터베이스에 저장됩니다.
  4. ZooKeeper: 멤버 자격 테이블은 ZooKeeper 앙상블에 저장됩니다.
  5. Consul: MembershipTableAssembly = "OrleansConsulUtils"를 사용하여 사용자 지정 시스템 저장소로 구성했습니다. 자세한 내용은 Consul-Deployment를 참조하세요.
  6. DynamoDB: MembershipTableAssembly = "OrleansAWSUtils"를 사용하여 사용자 지정 시스템 저장소로 구성했습니다.

모든 활동성 형식의 경우 공통 구성 변수는 Globals.Liveness 요소에 정의됩니다.

  1. ProbeTimeout: 다른 사일로의 활동성을 조사하거나 사일로가 자체에 대해 "I am alive" 하트비트 메시지를 보내는 데 걸리는 시간(초)입니다. 기본값은 10초입니다.
  2. TableRefreshTimeout: 멤버 자격 테이블에서 업데이트를 페치할 시간(초)입니다. 기본값은 60초입니다.
  3. DeathVoteExpirationTimeout: 멤버 자격 테이블의 종료 투표에 대한 만료 시간(초)입니다. 기본값은 120초입니다.
  4. NumMissedProbesLimit: 사일로에서 누락된 "I am alive" 하트비트 메시지의 수 또는 이 사일로를 종료한 것으로 의심하게 하는 응답되지 않은 프로브의 수입니다. 기본값은 3입니다.
  5. NumProbedSilos: 각 사일로가 활동성을 조사하는 사일로의 수입니다. 기본값은 3입니다.
  6. NumVotesForDeathDeclaration: 일부 사일로를 종료된 것으로 선언하는 데 필요한 만료되지 않은 투표 수입니다(최대 NumMissedProbesLimit여야 합니다). 기본값은 2입니다.
  7. UseLivenessGossip: 활동성 정보 확산 속도를 높이기 위해 가십 최적화를 사용할지 여부입니다. 기본값은 true입니다.
  8. IAmAliveTablePublishTimeout: 이 사일로가 활성 상태인 멤버 자격 테이블에 주기적으로 쓰는 시간(초)입니다. 진단용으로만 사용됩니다. 기본값은 5분입니다.
  9. NumMissedTableIAmAliveLimit: 경고가 기록되도록 하는 사일로의 테이블에서 누락된 "I am alive" 업데이트의 수입니다. 활동성 프로토콜에 영향을 주지 않습니다. 기본값은 2입니다.
  10. MaxJoinAttemptTime: 포기하기 전에 사일로 클러스터 조인을 시도하는 시간(초)입니다. 기본값은 5분입니다.
  11. ExpectedClusterSize: 클러스터의 예상 크기입니다. 매우 정확할 필요가 없으며 과대 평가될 수 있습니다. Azure 테이블에 쓰는 재시도의 지수 백오프 알고리즘을 조정하는 데 사용됩니다. 기본값은 20입니다.

디자인 근거

자연스럽게 제기될 수 있는 질문은 임시 노드가 있는 그룹 멤버십에 대한 즉각적인 지원을 잠재적으로 사용하여 클러스터 멤버십 구현을 Apache ZooKeeper에 전적으로 의존하지 않는 이유입니다. 멤버 자격 프로토콜 구현을 힘들게 한 이유는 무엇인가요? 주로 세 가지 이유가 있었습니다.

  1. 클라우드에서 배포/호스팅:

    Zookeeper는 호스트된 서비스가 아닙니다(적어도 2015년 7월 이 문서가 작성된 시점과 2011년 여름에 이 프로토콜을 처음 구현했을 때 주요 클라우드 공급자에서 호스트된 서비스로 실행하는 Zookeeper 버전은 없었음). 이는 클라우드 환경에서 Orleans 고객이 ZK 클러스터 인스턴스를 배포/실행/관리해야 함을 의미합니다. 이는 고객에게 강요하고 싶지 않았던 또 다른 불필요한 부담입니다. Azure Table을 사용함으로써 고객의 삶을 훨씬 더 간편하게 만드는 호스트된 관리형 서비스에 의존합니다. 기본적으로 클라우드에서는 클라우드를 인프라가 아닌 플랫폼으로 사용합니다. 반면, 온-프레미스를 실행하고 서버를 관리하는 경우 IMembershipTable의 구현으로 ZK를 사용하는 것이 실행 가능한 옵션입니다.

  2. 직접 오류 검색:

    임시 노드에서 ZK의 그룹 멤버 자격을 사용하는 경우 오류 검색은 Orleans 서버(ZK 클라이언트)와 ZK 서버 간에 수행됩니다. 이는 반드시 Orleans 서버 간의 실제 네트워크 문제와 연관되지 않을 수도 있습니다. 오류 감지는 통신의 클러스터 내 상태를 정확하게 반영하고자 했습니다. 특히, 디자인에서 Orleans 사일로가 IMembershipTable과 통신할 수 없는 경우 종료된 것으로 간주되지 않고 계속 작동할 수 있습니다. 이와는 대조적으로 ZK 서버와의 연결이 끊기면 ZK 그룹 멤버 자격을 사용했으므로 활성 상태이고 완벽하게 작동하는 동안 Orleans 사일로(ZK 클라이언트)가 종료된 것으로 선언될 수 있습니다.

  3. 이식성 및 유연성:

    Orleans의 철학의 일환으로, 특정 기술에 대한 강력한 의존을 강요하고 않고 다른 구성 요소를 다른 구현으로 쉽게 전환할 수 있는 유연한 디자인을 원합니다. 이것이 바로 IMembershipTable 추상화가 제공하는 목적입니다.

감사의 말

이 프로토콜의 첫 번째 버전의 디자인 및 구현에 대한 Alex Kogan의 기여를 인정합니다. 이 작업은 2011년 여름 Microsoft Research의 여름 인턴십의 일환으로 수행되었습니다. ZooKeeper 기반 IMembershipTable의 구현은 Shay Hazor에 의해 수행되었으며, SQL IMembershipTable의 구현은 Veikko Eeva에 의해 수행되었으며, AWS DynamoDB IMembershipTable의 구현은 Gutemberg Ribeiro에 의해 수행되었으며, Consul 기반 IMembershipTable의 구현은 Paul North에 의해 수행되었습니다.