다음을 통해 공유

Orleans에서의 클러스터 관리

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

프로토콜은 외부 서비스를 사용하여 IMembershipTable의 추상화를 제공합니다. IMembershipTable 는 두 가지 용도로 사용되는 평평하고 내구성이 뛰어난 테이블입니다. 첫째, 사일로들이 서로를 찾고 클라이언트가 사일로를 찾을 수 있는 만남의 지점입니다. 둘째, 현재 멤버십 뷰(활성 사일로 목록)를 저장하고 이 뷰에 대한 합의를 조정하는 데 도움을 줍니다.

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

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

멤버 자격 프로토콜

  1. 시작 시 모든 사일로는 IMembershipTable의 구현을 사용하여 잘 알려진 공유 테이블에 자신의 항목을 추가합니다. Orleans 는 테이블의 고유 키로 사일로 ID(ip:port:epoch) 및 서비스 배포 ID(클러스터 ID)의 조합을 사용합니다. Epoch는 단순히 이 사일로가 시작된 시간(틱 단위)이므로, ip:port:epoch 배포 내에서 Orleans가 고유하도록 보장합니다.

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

  3. 사일로 S가 모니터링 중인 서버 P에서 Y개의 프로브 응답을 받지 못할 경우, P를 의심하며 해당 의심의 타임스탬프를 P의 행에 IMembershipTable에 기록합니다.

  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. 스냅샷 브로드캐스트: 주기적인 표 읽기 빈도를 줄이기 위해 매번 사일로가 표에 데이터를 쓸 때(의심이나 새 조인 등) 현재 표 상태의 스냅샷을 다른 모든 사일로에 전송합니다. 멤버 자격 테이블은 일관되고 단조로 버전이 지정되므로 각 업데이트는 안전하게 공유할 수 있는 고유한 버전 스냅샷을 생성합니다. 이렇게 하면 주기적인 읽기 주기를 기다리지 않고 멤버 자격 변경을 즉시 전파할 수 있습니다. 스냅샷 배포가 실패할 경우 주기적 읽기는 대체 메커니즘으로 계속 유지됩니다.

  8. 순서가 지정된 멤버 자격 보기: 멤버 자격 프로토콜은 모든 멤버 자격 구성이 전역적으로 완전히 정렬되도록 합니다. 이 순서 지정은 다음 두 가지 주요 이점을 제공합니다.

    1. 연결 보장: 새 사일로가 클러스터에 합류하면 다른 모든 활성 사일로와의 양방향 연결을 확인해야 합니다. 기존 사일로가 응답하지 않는 경우(네트워크 연결 문제를 나타낼 수 있음) 새 사일로는 조인할 수 없습니다. 이렇게 하면 시작 시 클러스터의 모든 사일로 간에 전체 연결이 보장됩니다. 아래의 IAmAlive에 대한 메모를 참조하여 재해 복구 시나리오의 예외를 확인하세요.

    2. 일관된 디렉터리 업데이트: 분산된 그레인 디렉터리와 같은 상위 수준 프로토콜은 모든 사일로가 멤버 자격에 대한 일관되고 단조적인 보기를 유지하는 것을 필요로 합니다. 이렇게 하면 중복된 곡물 활성화를 보다 스마트하게 확인할 수 있습니다. 자세한 내용은 Grain 디렉터리 설명서를 참조하세요.

    구현 세부 정보:

    1. IMembershipTable는 변경 사항의 전역 총 순서를 보장하기 위해 원자적 업데이트가 필요합니다.

      • 구현에서는 테이블 항목(사일로 목록)과 버전 번호를 한 번에 업데이트해야 합니다.
      • SQL Server에서와 같이 데이터베이스 트랜잭션을 사용하거나 ETag를 사용하여 원자성 비교 및 교환 작업을 수행합니다(Azure Table Storage에서와 같이).
      • 특정 메커니즘은 기본 스토리지 시스템의 기능에 따라 달라집니다.

    2. 테이블의 특수 멤버 자격 버전 행은 변경 내용을 추적합니다.

      • 테이블에 쓸 때마다(의심, 사망 선언, 조인) 이 버전 번호가 증가합니다.
      • 모든 쓰기는 원자성 업데이트를 사용하여 이 행을 통해 직렬화됩니다.
      • 단조로 증가하는 버전은 모든 멤버 자격 변경의 총 순서를 보장합니다.

    3. 사일로 S가 사일로 P의 상태를 업데이트하는 경우:

      • S는 먼저 최신 테이블 상태를 읽습니다.
      • 단일 원자성 작업에서 P의 행을 모두 업데이트하고 버전 번호를 증분합니다.
      • 원자성 업데이트가 실패하는 경우(예: 동시 수정으로 인해) 작업은 지수 백오프를 사용하여 다시 시도합니다.

    확장성 고려 사항:

    버전 행을 통해 모든 쓰기를 직렬화하면 경합 증가로 인해 확장성에 영향을 줄 수 있습니다. 이 프로토콜은 최대 200개의 사일로를 사용하여 프로덕션에서 효과적인 것으로 입증되었지만 1,000개 이상의 사일로를 초과하는 문제에 직면할 수 있습니다. 매우 큰 배치의 경우 멤버 자격 업데이트가 병목 현상이 되더라도 Orleans의 다른 부분(메시징, 그레인 디렉토리, 호스팅)은 확장성을 유지합니다.

  9. 기본 구성: 기본 구성은 Azure에서 프로덕션 사용 중에 직접 조정되었습니다. 기본적으로: 모든 사일로는 세 개의 다른 사일로에 의해 모니터링되고, 두 개의 이상이 사일로를 정지된 것으로 선언하기에 충분하며, 이상은 지난 3분 동안의 것만 고려됩니다(그렇지 않으면 구식으로 간주됨). 프로브는 10초마다 전송되며, 세 개의 프로브를 놓치면 사일로가 의심됩니다.

  10. 자체 모니터링: 고장 감지기는 Hashicorp의 Lifeguard 연구(논문, 강연, 블로그)에서 아이디어를 차용하여, 클러스터의 상당 부분이 부분 실패를 경험할 때 발생하는 치명적인 사건들 동안 클러스터의 안정성을 개선합니다. LocalSiloHealthMonitor 구성 요소는 여러 추론을 사용하여 각 사일로의 상태에 점수를 매기고 있습니다.

    • 멤버 자격 테이블의 활성 상태
    • 다른 사일로에서 의심이 없음
    • 최근 성공적인 탐사 응답
    • 최근 프로브 요청이 수신됨
    • 스레드 풀 응답성(1초 이내에 실행되는 작업 항목)
    • 타이머 정확도(일정의 3초 이내에 실행)

    사일로의 상태 점수는 프로브 시간 제한에 영향을 줍니다. 비정상 사일로(점수 1-8)는 건강한 사일로(점수 0)에 비해 시간 제한이 증가했습니다. 이렇게 하면 다음 두 가지 이점이 제공됩니다.

    • 네트워크 또는 시스템이 스트레스를 받을 때 프로브가 성공하는 데 더 많은 시간을 제공합니다.
    • 건강에 해로운 사일로가 건강한 사일로를 잘못된 투표로 제거하기 전에, 죽은 것으로 간주될 가능성이 더 높아집니다.

    이는 스레드 풀 부족과 같은 시나리오에서 특히 유용합니다. 이 경우 느린 노드는 응답을 충분히 신속하게 처리할 수 없기 때문에 정상 노드를 잘못 의심할 수 있습니다.

  11. 간접 검색: 비정상 또는 분할된 사일로가 정상 사일로를 잘못 사망 처리할 가능성을 줄여 오류 감지의 정확성을 높이는 또 다른 Lifeguard에서 영감을 받은 기능입니다. 모니터링 사일로가 대상 사일로가 죽었다고 선언하는 투표를 하기 전에 두 번의 프로브 시도가 남아 있다면, 간접 프로브를 사용합니다.

    • 모니터링 사일로는 임의로 다른 사일로를 중개자로 선택하고 대상을 조사하도록 요청합니다.
    • 중개자가 대상 사일로에 연결하려고 시도합니다.
    • 대상이 시간 제한 기간 내에 응답하지 않으면 중간자가 부정적인 승인을 보냅니다.
    • 모니터링 사일로가 중개자로부터 부정적 응답을 받으면, 중개자가 (위에서 설명한 자체 모니터링을 통해) 자신을 정상이라고 선언할 경우, 모니터링 사일로는 대상을 비활성화된 것으로 선언하는 투표를 진행합니다.
    • 기본적으로 두 개의 필수 투표가 필요하며, 간접 탐색에서 부정 응답이 두 투표로 계산되므로 여러 관점에서 실패가 확인될 때 데드 사일로를 더 빠르게 선언할 수 있습니다.

  12. 완벽한 실패 감지 적용: 테이블에서 사일로가 데드로 선언되면, 모두가 심지어 실제로 죽은 것이 아닐지라도(예: 일시적으로 분할되었거나 하트비트 메시지가 손실된 경우) 사일로를 죽은 것으로 간주합니다. 모든 사람이 통신을 중지합니다. 사일로가 테이블에서 새 상태를 읽고 죽었다는 것을 알면 프로세스를 종료합니다. 따라서 새로운 프로세스로 사일로를 재시작하려면 적절한 인프라가 필요합니다(시작 시 새로운 시기 번호가 생성됩니다). Azure에서 호스트되는 경우 자동으로 발생합니다. 그렇지 않으면 실패 시 자동 다시 시작하도록 구성된 Windows 서비스 또는 Kubernetes 배포와 같은 다른 인프라가 필요합니다.

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

    스토리지 서비스가 다운되거나 사용할 수 없거나 통신 문제가 발생하는 경우, 프로토콜은 사일로를 실수로 중단된 것으로 간주하지 않습니다. 운영 부문은 문제 없이 계속 작동합니다. 그러나 Orleans는 사일로가 중단됨을 선언할 수 없으며(누락된 프로브로 인해 죽은 사일로를 감지하더라도 이 사실을 테이블에 쓸 수 없으므로) 새 사일로가 조인하는 것을 허용할 수 없습니다. 따라서 완전성은 저하되지만 정확도는 저하되지 않습니다. 테이블에서 분할하더라도 Orleans이 사일로가 죽었다고 잘못 선언하지 않습니다. 일부 사일로가 테이블에 접근할 수 있고 다른 사일로는 접근할 수 없는 Orleans 부분 네트워크 파티션에서는 사일로를 죽은 것으로 선언할 수 있지만, 다른 모든 사일로가 이를 인식하는 데는 시간이 걸립니다. 감지는 지연될 수 있지만 Orleans 테이블 사용 불가로 인해 절대로 사일로를 잘못 종료하지 않습니다.

  14. IAmAlive 진단 및 재해 복구용으로 작성:

    사일로 간에 전송되는 하트비트 외에도 각 사일로는 테이블 행에서 "I Am Alive" 타임스탬프를 주기적으로 업데이트합니다. 이는 다음 두 가지 용도로 사용됩니다.

    1. 진단: 시스템 관리자에게 클러스터의 활성 상태를 확인하고 사일로가 마지막으로 활성화된 시간을 확인할 수 있는 간단한 방법을 제공합니다. 타임스탬프는 기본적으로 30초마다 업데이트됩니다.

    2. 재해 복구: 사일로가 여러 기간 동안 타임스탬프를 업데이트하지 않은 경우(이 기간은 NumMissedTableIAmAliveLimit을 통해 구성되며 기본값은 3임), 새 사일로는 시작 시 연결 검사를 할 때 해당 사일로를 무시합니다. 이를 통해 클러스터는 적절한 정리 없이 사일로가 충돌한 시나리오에서 복구할 수 있습니다.

멤버 자격 테이블

언급했듯이 IMembershipTable는 사일로가 서로를 찾고 Orleans 클라이언트가 사일로를 찾기 위한 랑데부 지점 역할을 합니다. 또한 멤버십 견해에 대한 동의를 조정하는 데도 도움이 됩니다. 주 Orleans 리포지토리에는 Azure Table Storage, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB 및 개발을 위한 메모리 내 구현을 비롯한 많은 시스템에 대한 구현이 포함되어 있습니다.

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

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

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

  4. Consul IO: Consul의 키/값 저장소는 멤버 자격 테이블을 구현하는 데 사용되었습니다. 자세한 내용은 Consul 배포를 참조하세요.

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

  6. Apache Cassandra: 이 구현에서 서비스 ID 및 클러스터 ID의 복합은 파티션 키로 사용되고, 사일로 ID()는ip:port:epoch 행 키로 사용됩니다. 그들은 함께 각 사일로에 대해 고유한 행을 보장합니다. 동시성 제어의 경우 경량 트랜잭션을 사용하는 정적 열 버전을 기반으로 하는 낙관적 동시성 제어가 사용됩니다. 이 버전 열은 파티션/클러스터의 모든 행에 대해 공유되며 각 클러스터의 멤버 자격 테이블에 대해 일관된 증가 버전 번호를 제공합니다. 이 구현에는 여러 행 트랜잭션이 없습니다.

  7. 개발 설정을 위한 메모리 내 에뮬레이션: 이 구현에 특수 시스템 곡물이 사용됩니다. 이 곡물은 개발 설정에만 사용되는 지정된 기본 사일로에 있습니다. 실제 생산 사용에서는 기본 사일로 가 필요하지 않습니다.

디자인 근거

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

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

    Zookeeper는 호스트된 서비스가 아닙니다. 즉, Orleans 클라우드 환경에서 고객은 ZK 클러스터의 인스턴스를 배포, 실행 및 관리해야 합니다. 이는 고객에게 강요되지 않은 불필요한 부담입니다. Azure Table Orleans 을 사용하면 호스트된 관리형 서비스를 사용하여 고객의 삶을 훨씬 더 간단하게 만듭니다. 기본적으로 클라우드에서는 클라우드를 인프라가 아닌 플랫폼으로 사용합니다. 반면, 온프레미스를 운영하고 서버를 관리할 때 ZK를 구현 IMembershipTable 으로 사용하는 것이 좋은 선택입니다.

  2. 직접 오류 검색:

    ZK의 그룹 멤버 자격을 임시 노드와 함께 사용하는 경우, Orleans 서버(ZK 클라이언트)와 ZK 서버 간의 오류 감지가 발생합니다. 이는 서버 간의 Orleans 실제 네트워크 문제와 반드시 관련이 있는 것은 아닙니다. 오류 감지는 클러스터 내 통신 상태를 정확하게 반영하고자 했습니다. 특히 이 디자인에서는 Orleans 사일로가 IMembershipTable와 통신할 수 없더라도 죽은 것으로 간주되지 않으며 계속해서 작업을 수행할 수 있습니다. 반면, 임시 노드를 사용하는 ZK 그룹 멤버십의 경우 ZK 서버와의 연결이 끊어지면 Orleans 사일로(ZK 클라이언트)가 죽은 것으로 선언될 수 있지만 실제로는 활성화되어 완벽히 운영되는 경우입니다.

  3. 이식성 및 유연성:

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

멤버 자격 프로토콜의 속성

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

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

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

    실제 탐침은 테이블이 아닌 서버 간에 직접 이동합니다. 테이블을 통해 프로브를 라우팅하면 상당한 트래픽이 발생하며, 장애 감지 관점에서 덜 정확해질 수 있습니다. 사일로가 테이블에 도달하지 못하면 자신의 "나는 살아있다" 하트비트를 기록하지 못하고, 다른 사일로들이 이를 죽었다고 간주하게 됩니다.

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

    비록 완벽하고 정확한 장애 감지를 모두 달성할 수는 없지만, 보통은 정확성(라이브 사일로를 죽었다고 선언하지 않기)과 완전성(죽은 사일로를 가능한 한 빨리 죽었다고 선언하기)의 절충을 가능하게 하는 기능을 원하는 경우가 많습니다. 죽은 프로브와 누락된 프로브를 선언할 수 있는 구성 가능한 투표는 이 두 가지 측면 간의 균형을 조정할 수 있게 합니다. 자세한 내용은 예일 대학교: 컴퓨터 과학 오류 탐지기를 참조하세요.

  4. 크기 조정:

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

  5. 진단:

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

  6. 다음을 구현IMembershipTable하는 데 신뢰할 수 있는 영구 스토리지가 필요한 이유는 무엇인가요?

    영구 스토리지는 두 가지 용도로 IMembershipTable 사용됩니다. 첫째, 사일로들이 서로를 찾고 클라이언트가 사일로를 찾을 수 있는 만남의 지점입니다. 둘째, 신뢰할 수 있는 스토리지는 멤버 자격 보기에 대한 규약을 조정하는 데 도움이 됩니다. 실패 감지는 사일로 간에서 직접 피어 투 피어로 수행되지만 멤버십 뷰는 신뢰할 수 있는 스토리지에 저장되며, 이 스토리지에서 제공하는 동시성 제어 메커니즘은 누가 활성 상태인지 또는 비활성 상태인지 합의하는 데 사용됩니다. 어떤 의미에서 이 프로토콜은 분산 합의의 어려운 문제를 클라우드에 아웃소싱합니다. 이렇게 하면 기본 클라우드 플랫폼의 모든 기능을 활용하여 실제로 PaaS(Platform as a Service)로 사용합니다.

  7. 진단용으로만 테이블에 직접 IAmAlive 쓰기:

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

감사의 말

이 프로토콜의 첫 번째 버전의 디자인 및 구현에 Alex Kogan의 기여를 인정합니다. 이 작업은 2011년 여름 Microsoft Research에서 여름 인턴십의 일환으로 수행되었습니다. ZooKeeper 기반 IMembershipTable 의 구현은 셰이 하저에 의해 수행되었다, SQL IMembershipTable 의 구현은 Veikko Eeva에 의해 수행되었다, AWS DynamoDB IMembershipTable 의 구현은 구템베르크 리베이로에 의해 수행되었다, Consul 기반 IMembershipTable 의 구현은 폴 노스에 의해 수행되었다, 마지막으로 Apache Cassandra IMembershipTable 의 구현은 OrleansCassandraUtils에 의해 조정되었다.

  • Last updated on