Orleans의 클러스터 관리

아티클
01/09/2025

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

프로토콜은 외부 서비스를 사용하여 IMembershipTable의 추상화를 제공합니다. IMembershipTable 두 가지 용도로 사용하는 플랫 내구성 테이블입니다. 첫째, 사일로가 서로를 찾고, Orleans 클라이언트가 사일로를 찾는 랑데부 지점으로 사용됩니다. 둘째, 현재 멤버 자격 보기(활성 사일로 목록)를 저장하고 멤버 자격 보기에 대한 규약을 조정하는 데 사용됩니다.

현재 Azure Table Storage, Azure Cosmos DB, ADO.NET(PostgreSQL, 기반) 6가지 구현이 있습니다. MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS DynamoDB, MongoDB, Redis, Apache Cassandra및 개발을 위한 메모리 내 구현.

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

멤버 자격 프로토콜

시작 시 모든 사일로는 IMembershipTable 구현을 사용하여 잘 알려진 공유 테이블에 자체 항목을 추가합니다. 사일로 ID(ip:port:epoch)와 서비스 배포 ID(클러스터 ID)의 조합은 테이블에서 고유 키로 사용됩니다. Epoch는 이 사일로가 시작된 틱 단위의 시간이므로 ip:port:epoch는 지정된 Orleans 배포에서 고유함이 보장됩니다.
사일로는 애플리케이션 프로브("are you alive" heartbeats)를 통해 서로를 직접 모니터링합니다. 프로브는 사일로 간에 직접 메시지로 전송되며, 이는 사일로가 통신하는 동일한 TCP 소켓을 통해 이루어집니다. 이렇게 하면 프로브는 실제 네트워킹 문제 및 서버 상태와 완전히 상관 관계가 있습니다. 모든 사일로는 구성할 수 있는 다른 사일로 집합을 탐색합니다. 사일로는 다른 사일로들의 ID에 대해 일관된 해싱을 수행하여 각 ID의 가상 링을 형성하고, 그 링에서 X개의 후속 사일로를 선택하여 어떤 사일로를 조사할지 결정합니다. 이는 잘 알려진 분산 기법인 일관된 해싱이며 Chord DHT와 같은 많은 분산 해시 테이블에서 널리 사용됩니다.
사일로 S가 모니터링되는 서버 P에서 Y 프로브 응답을 받지 못하면 타임스탬프가 지정된 의혹을 IMembershipTableP의 행에 기록하여 의심합니다.
P가 K초 내에 Z회 이상의 의심을 받게 되면 S는 P가 죽었다고 해당 행에 기록하고, 현재 멤버십 테이블의 스냅샷을 다른 모든 사일로로 보냅니다. 사일로는 테이블을 주기적으로 새로 고치므로 스냅샷은 모든 사일로가 새 멤버 자격 보기에 대해 학습하는 데 걸리는 시간을 줄이기 위한 최적화입니다.
자세한 정보:
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에서 제공하는 낙관적 동시성을 사용합니다.
모든 사일로는 배포에 대한 전체 멤버 자격 테이블을 주기적으로 읽습니다. 이러한 방식으로 사일로가 새로운 사일로 조인과 다른 사일로가 종료된 것으로 선언되는 것에 대해 알아봅니다.
스냅샷 전송: 주기적인 테이블 읽기 빈도를 줄이기 위해 사일로가 테이블에 기록할 때마다(의심, 새로운 참여 등) 현재 테이블 상태의 스냅샷을 다른 모든 사일로에 보냅니다. 멤버 자격 테이블은 일관되고 단조로 버전이 지정되므로 각 업데이트는 안전하게 공유할 수 있는 고유한 버전 스냅샷을 생성합니다. 이렇게 하면 주기적인 읽기 주기를 기다리지 않고 멤버 자격 변경을 즉시 전파할 수 있습니다. 스냅샷 배포가 실패할 경우 주기적 읽기는 대체 메커니즘으로 계속 유지됩니다.
순서가 지정된 멤버 자격 보기: 멤버 자격 프로토콜은 모든 멤버 자격 구성이 전역적으로 완전히 정렬되도록 합니다. 이 순서 지정은 다음 두 가지 주요 이점을 제공합니다.
1. 연결 보장: 새 사일로가 클러스터에 합류하면 다른 모든 활성 사일로와의 양방향 연결을 확인해야 합니다. 기존 사일로가 응답하지 않는 경우(네트워크 연결 문제를 나타낼 수 있음) 새 사일로는 합류할 수 없습니다. 이렇게 하면 시작 시 클러스터의 모든 사일로 간에 전체 연결이 보장됩니다. 재해 복구의 경우 예외는 아래 IAmAlive에 대한 참고 사항을 참조하세요.
2. 일관된 디렉터리 업데이트: 분산된 그레인 디렉터리와 같은 상위 수준 프로토콜은 모든 사일로가 멤버 자격에 대해 일관되고 단조적인 관점을 유지하는 것에 의존합니다. 이렇게 하면 중복된 곡물 활성화를 보다 스마트하게 확인할 수 있습니다. 자세한 내용은 grain 디렉터리 설명서를 참조하세요.
구현 세부 정보:
1. IMembershipTable는 변경 사항의 전역 총 순서를 보장하기 위해 원자적 업데이트가 필요합니다.
  - 구현은 테이블의 항목(사일로 목록)과 버전 번호를 원자적으로 업데이트되어야 합니다.
  - 이 작업은 데이터베이스 트랜잭션(SQL Server에서와 같이) 또는 ETag를 사용하는 원자성 비교 및 교환 작업(Azure Table Storage에서와 같이)을 사용하여 수행할 수 있습니다.
  - 특정 메커니즘은 기본 스토리지 시스템의 기능에 따라 달라집니다.
2. 테이블의 특수 멤버 자격 버전 행은 변경 내용을 추적합니다.
  - 테이블에 쓸 때마다(의심, 사망 선언, 조인) 이 버전 번호가 증가합니다.
  - 모든 쓰기는 이 행을 통해 원자성 업데이트 방식으로 직렬화됩니다.
  - 단조로 증가하는 버전은 모든 멤버 자격 변경의 총 순서를 보장합니다.
3. 사일로 S가 사일로 P의 상태를 업데이트하는 경우:
  - S는 먼저 최신 테이블 상태를 읽습니다.
  - 단일 원자성 작업에서 P의 행을 모두 업데이트하고 버전 번호를 증분합니다.
  - 원자성 업데이트가 실패하는 경우(예: 동시 수정으로 인해) 작업은 지수 백오프를 사용하여 다시 시도됩니다.
확장성 고려 사항은 다음과.

버전 행을 통해 모든 쓰기를 직렬화하면 경합 증가로 인해 확장성에 영향을 줄 수 있습니다. 이 프로토콜은 최대 200개의 사일로와 함께 프로덕션에서 검증되었지만, 천 개 이상의 사일로에서는 문제에 직면할 가능성이 있습니다. 매우 큰 배치의 경우 멤버 자격 업데이트가 병목 현상이 되더라도 Orleans의 다른 부분(메시징, 그레인 디렉토리, 호스팅)은 확장성을 유지합니다.
기본 구성: 기본 구성은 Azure에서 프로덕션 사용 중에 직접 조정되었습니다. 기본적으로: 모든 사일로는 세 개의 다른 사일로에 의해 모니터링되며, 두 개의 의심만으로 사일로를 활성 상태가 아니라고 선언하기에 충분하며, 지난 3분 동안의 의심만 유효합니다(그렇지 않으면 오래된 것으로 간주됩니다). 프로브는 10초마다 전송되며, 사일로의 존재를 의심하려면 프로브를 세 번 연속 놓쳐야 합니다.
자체 모니터링: 고장 감지기는 Hashicorp의 Lifeguard 연구(논문, 강연, 블로그)에서 아이디어를 차용하여, 클러스터의 상당 부분이 부분 실패를 경험할 때 발생하는 치명적인 사건들 동안 클러스터의 안정성을 개선합니다. LocalSiloHealthMonitor 구성 요소는 여러 추론을 사용하여 각 사일로의 상태에 점수를 매기고 있습니다.
- 회원 테이블의 활성 상태
- 다른 사일로에서 의심이 없음
- 최근 성공적인 탐사 응답
- 최근 프로브 요청이 수신됨
- 스레드 풀 응답성(1초 이내에 실행되는 작업 항목)
- 타이머 정확도(일정의 3초 이내에 실행)
사일로의 상태 점수는 프로브 시간 제한에 영향을 줍니다. 비정상 사일로(점수 1-8)는 건강한 사일로(점수 0)에 비해 시간 제한이 증가했습니다. 다음과 같은 두 가지 이점이 있습니다.
- 네트워크 또는 시스템이 스트레스를 받을 때 프로브가 성공할 수 있는 더 많은 시간을 제공합니다.
- 건강에 해로운 사일로가 정상 사일로를 잘못 제거하기 전에 죽은 것으로 간주될 가능성을 높입니다.
이는 스레드 풀 부족과 같은 시나리오에서 특히 유용합니다. 이 경우 느린 노드는 응답을 충분히 신속하게 처리할 수 없기 때문에 정상 노드를 잘못 의심할 수 있습니다.
간접 조사: 비정상 또는 분할된 사일로가 정상 사일로 사망을 잘못 선언할 가능성을 줄여 오류 감지 정확도를 향상시키는 또 다른 인명 구조원영감을 받은 기능입니다. 모니터링 사일로가 대상 사일로가 죽었다고 선언하는 투표를 하기 전에 두 번의 프로브 시도가 남아 있다면, 간접 프로브를 사용합니다.
- 모니터링 사일로는 다른 사일로를 중개자로 임의로 선택한 후 대상을 탐색하도록 요청합니다.
- 중개자가 대상 사일로에 연결하려고 시도합니다.
- 대상이 시간 제한 기간 내에 응답하지 못하면 중간자가 부정적인 승인을 보냅니다.
- 모니터링 사일로가 중개자로부터 부정적인 응답을 받았고 중개인이 (위에서 설명한 자체 모니터링을 통해) 건강하다고 선언하는 경우 모니터링 사일로는 대상을 죽은 것으로 선언하도록 투표합니다.
- 두 개의 필수 투표 기본 설정을 사용하면, 간접 프로브에서의 부정 승인도 두 투표로 간주되어, 여러 관점에서 실패가 확인되면 비활성 사일로를 보다 신속하게 선언할 수 있습니다.
완벽한 실패 감지적용: 테이블에서 사일로가 죽은 것으로 선언되면, 일시적으로 분할되거나 하트비트 메시지가 손실되어 실제로 죽지 않았더라도 모두 사일로를 죽은 것으로 간주합니다. 모두가 통신을 중지하고 테이블에서 새로운 상태를 읽음으로써 중단된 것을 알게 되면 해당 프로세스를 종료합니다. 따라서 새 프로세스로 사일로를 다시 시작하는 인프라가 있어야 합니다(시작 시 새 epoch 번호가 생성됨). Azure에서 호스트되면 자동으로 발생합니다. 그렇지 않은 경우 실패 시 자동 다시 시작하도록 구성된 Windows 서비스 또는 Kubernetes 배포와 같은 다른 인프라가 필요합니다.
일정 시간 동안 테이블에 액세스할 수 없으면 어떻게 되나요?

스토리지 서비스가 다운되거나 사용할 수 없거나 통신 문제가 있는 경우 Orleans 프로토콜은 실수로 사일로를 중단된 것으로 선언하지 않습니다. 운영 사일로는 아무런 문제 없이 계속 작동합니다. 그러나 Orleans는 사일로의 종료를 선언할 수 없으며(누락된 프로브로 인해 사일로가 종료된 것을 감지하더라도 이를 테이블에 기록할 수 없습니다) 또한 신규 사일로의 참여를 허용할 수 없습니다. 따라서 완전성은 저하되지만 정확도는 유지됩니다. 테이블에서의 분할로 인해 Orleans가 실수로 사일로를 죽은 것으로 선언하지 않습니다. 또한 부분 네트워크 파티션의 경우(일부 사일로가 테이블에 액세스할 수 있고 일부는 액세스할 수 없는 경우) Orleans가 데드 사일로를 종료로 선언할 수 있지만 다른 모든 사일로가 이에 대해 알게 될 때까지 약간의 시간이 걸릴 수 있습니다. 따라서 검색이 지연될 수 있지만 Orleans는 테이블을 사용할 수 없어서 사일로를 잘못 종료하지 않습니다.
진단 및 재해 복구를 위한 IAmAlive의 글:

사일로 간에 전송되는 하트비트 외에도 각 사일로는 테이블의 행에서 "I Am Alive" 타임스탬프를 주기적으로 업데이트합니다. 이는 다음 두 가지 용도로 사용됩니다.
1. 시스템 관리자가 진단할 때 클러스터의 가용성을 확인하고 사일로가 마지막으로 활성화된 시점을 간단하게 확인할 수 있는 방법을 제공합니다. 타임스탬프는 일반적으로 5분마다 업데이트됩니다.
2. 재해 복구의 경우, 사일로가 여러 기간 동안 타임스탬프를 업데이트하지 않은 경우(NumMissedTableIAmAliveLimit를 통해 구성), 새 사일로는 시작 시 연결 검사에서 이를 무시하여 사일로가 적절한 정리 없이 중단된 시나리오에서도 클러스터가 복구할 수 있도록 합니다.

멤버 자격 테이블

이미 언급했듯이 IMembershipTable은 사일로가 사일로를 찾을 수 있는 랑데부 지점으로 사용되고 있으며, 사일로를 찾을 수 있는 Orleans 클라이언트를 찾고 멤버 자격 보기에 대한 규약을 조정하는 데도 도움이 됩니다. 기본 Orleans 리포지토리에는 Azure Table Storage, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB 및 개발을 위한 메모리 내 구현과 같은 많은 시스템에 대한 구현이 포함되어 있습니다.

Azure Table Storage - 이 구현에서는 Azure 배포 ID를 파티션 키로 사용하고, 사일로 ID(ip:port:epoch)를 행 키로 사용합니다. 함께 사일로당 고유한 키를 보장합니다. 동시성 제어의 경우 Azure Table ETags를 기반으로 낙관적 동시성 제어를 사용합니다. 테이블에서 읽을 때마다 모든 읽기 행에 대한 ETag를 저장하고 쓰기 저장하려고 할 때 해당 ETag를 사용합니다. ETag는 모든 쓰기에 대해 Azure Table Service에서 자동으로 할당되고 확인됩니다. 다중 행 트랜잭션의 경우 Azure 테이블에서 제공하는 일괄 처리 트랜잭션에 대한 지원을 활용하여 동일한 파티션 키가 있는 행을 통해 직렬화 가능한 트랜잭션을 보장합니다.
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에서 확인할 수 있습니다.
Apache ZooKeeper - 이 구현에서는 구성된 배포 ID를 루트 노드로 사용하고 자식 노드로 사일로 ID(ip:port@epoch)를 사용합니다. 함께 사일로당 고유한 경로를 보장합니다. 동시성 제어의 경우 노드 버전을 기반으로 낙관적 동시성 제어를 사용합니다. 배포 루트 노드에서 읽을 때마다 모든 읽기 자식 사일로 노드에 대한 버전을 저장하고 다시 쓰려고 할 때 해당 버전을 사용합니다. 노드의 데이터가 변경될 때마다 버전 번호는 ZooKeeper 서비스에 의해 원자성으로 증가합니다. 다중 행 트랜잭션의 경우 동일한 부모 배포 ID 노드가 있는 사일로 노드를 통해 직렬화 가능한 트랜잭션을 보장하는 다중 메서드를 활용합니다.
Consul IO - Consul의 키/값 저장소를 사용하여 멤버 자격 테이블을 구현했습니다. 자세한 내용은 Consul-Deployment를 참조하세요.
AWS DynamoDB - 이 구현에서는 클러스터 배포 ID를 파티션 키로 사용하고 사일로 ID(ip-port-generation)를 RangeKey로 사용하여 레코드 통합을 만듭니다. 낙관적 동시성은 DynamoDB에서 조건부 쓰기를 수행하여 ETag 특성에 의해 이루어집니다. 구현 논리는 Azure Table Storage와 매우 유사합니다.
Apacha Cassandra - 이 구현에서는 서비스 ID 및 클러스터 ID의 복합을 파티션 키로 사용하고 사일로 ID(ip:port:epoch)를 행 키로 사용합니다. 함께하면 각 사일로에 고유한 행을 보장합니다. 동시성 제어를 위해, 우리는 정적 열 버전에 기반한 경량 트랜잭션을 사용하는 낙관적 동시성 제어를 사용합니다. 이 버전 열은 파티션/클러스터의 모든 행에 대해 공유되므로 각 클러스터의 멤버 자격 테이블에 대한 일관된 증가 버전 번호를 제공합니다. 이 구현에는 여러 행 트랜잭션이 없습니다.
개발 설정을 위한 메모리 내 에뮬레이션입니다. 해당 구현에 특수 시스템 곡물을 사용합니다. 이 조직은 개발 설정에만 사용되는 지정된 기본 사일로에 있습니다. 실제 프로덕션 사용 시 기본 사일로는 필요하지 않습니다.

디자인 근거

자연스러운 질문은 왜 클러스터 멤버 자격 구현을 위해 임시 노드가 있는 그룹 멤버 자격에 대한 ZooKeeper의 기본 지원을 사용하여 Apache ZooKeeper 또는 etcd 에 완전히 의존하지 않는가입니다. 멤버 자격 프로토콜 구현을 힘들게 한 이유는 무엇인가요? 주로 세 가지 이유가 있었습니다.

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

Zookeeper는 호스트된 서비스가 아닙니다. 이는 클라우드 환경에서 Orleans 고객이 ZK 클러스터 인스턴스를 배포/실행/관리해야 함을 의미합니다. 이는 고객에게 강요하고 싶지 않았던 또 다른 불필요한 부담입니다. Azure Table을 사용함으로써 고객의 삶을 훨씬 더 간편하게 만드는 호스트된 관리형 서비스에 의존합니다. 기본적으로 클라우드에서는 클라우드를 인프라가 아닌 플랫폼으로 사용합니다. 반면, 온-프레미스를 실행하고 서버를 관리하는 경우 IMembershipTable의 구현으로 ZK를 사용하는 것이 실행 가능한 옵션입니다.
직접 오류 검색:

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

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

멤버 자격 프로토콜의 속성

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

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

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

완벽하고 정확한 오류 감지를 모두 달성할 수는 없지만, 일반적으로 정확성(라이브 사일로를 종료로 선언하고 싶지 않음)과 완전성(종료된 사일로를 최대한 빨리 종료로 선언하기를 원함)을 절충하는 기능을 원합니다. 죽은 프로브와 누락된 프로브를 선언하는 설정 가능한 투표는 이 두 가지를 교환할 수 있게 해줍니다. 자세한 내용은 예일 대학교: 컴퓨터 과학 오류 감지기를 참조하세요.
스케일링:

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

이 테이블은 진단 및 문제 해결에도 매우 편리합니다. 시스템 관리자는 테이블에서 활성 사일로의 현재 목록을 즉시 찾을 수 있으며 종료된 모든 사일로 및 주의 대상의 역사를 볼 수 있습니다. 이는 문제를 진단할 때 특히 유용합니다.
구현을 위해 안정적인 영구 스토리지가 필요한 이유는 다음과 같습니다IMembershipTable.

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

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

감사의 말

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

다음을 통해 공유