Azure 서비스 패브릭에서 재해 복구

  • 아티클

고가용성 전달의 중요한 부분은 서비스가 다양한 유형의 오류를 전부 해결할 수 있는지 확인하는 것입니다. 계획되지 않았으며 사용자 통제하에 있지 않은 오류의 경우 특히 이러한 과정이 중요합니다.

이 문서에서는 올바르게 모델링 및 관리되지 않으면 재해가 될 수 있는 몇 가지 일반적인 오류 모드에 대해 설명합니다. 또한 재해가 발생할 경우 수행해야 할 완화 조치 및 작업에 대해서 설명합니다. 목표는 계획 여부와 관계없이 오류가 발생할 때 가동 중지 시간 또는 데이터 손실의 위험을 없애거나 제한하는 것입니다.

재해 방지

Azure Service Fabric의 기본 목표는 일반적인 오류 유형이 재해로 발전하지 않도록 사용자의 환경 및 서비스를 모델링하는 데 도움을 주는 것입니다.

일반적으로 다음과 같은 두 가지 유형의 재해/오류 시나리오가 있습니다.

  • 하드웨어 및 소프트웨어 오류
  • 작동 오류

하드웨어 및 소프트웨어 오류

하드웨어 및 소프트웨어 오류는 예측할 수 없습니다. 오류를 해결하는 가장 쉬운 방법은 하드웨어 또는 소프트웨어 오류 경계의 전반에 걸쳐서 여러 서비스 사본을 실행하는 것입니다.

예를 들어 서비스가 특정 머신 한 대에서만 실행되는 경우 해당 머신의 오류는 서비스의 입장에서 재해가 됩니다. 해당 재해를 방지하는 간단한 방법은 서비스가 실제로 여러 머신에서 실행되도록 하는 것입니다. 한 머신의 오류로 인해 실행 중인 서비스가 중단되지 않는지 테스트할 필요도 있습니다. 용량 계획을 통해 다른 위치에 대체 인스턴스를 만들 수 있으며 용량이 감소해도 나머지 서비스에 과부하가 발생하지 않도록 할 수 있습니다.

오류 방지를 위해 어떤 작업을 수행하는지에 관계없이 동일한 패턴이 적용됩니다. 예를 들어 SAN에 문제가 있는 것이 확실한 경우 여러 SAN에 걸쳐 실행합니다. 서버 랙이 부족한 경우 여러 랙에 걸쳐 실행합니다. 데이터 센터의 손실이 걱정될 경우 여러 Azure 지역, 여러 Azure 가용성 영역 또는 자체 데이터 센터에 걸쳐 서비스를 실행해야 합니다.

서비스가 여러 물리적 인스턴스(머신, 랙, 데이터 센터, 지역)에 걸쳐 있는 경우에도 여전히 몇 가지 유형의 동시 오류가 발생할 수 있습니다. 하지만 특정 유형(예: 단일 가상 머신 또는 네트워크 연결 실패)의 단일 또는 다수로 발생하는 오류가 자동으로 처리되므로 더는 “재해”가 아니게 됩니다.

Service Fabric은 클러스터를 확장하기 위한 메커니즘을 제공하고 실패한 노드 및 서비스를 처리하여 다시 작동시킵니다. 또한 Service Fabric은 서비스의 여러 인스턴스 실행을 지원하여 계획되지 않은 오류가 실제 재해가 되지 않도록 합니다.

어떤 이유로 인해서 오류를 포괄할 만큼 충분히 큰 배포를 실행하는 것이 불가능할 수 있습니다. 예를 들어 오류 발생 가능성에 따라 기꺼이 지불할 용의가 있는 수준보다 더 많은 하드웨어 리소스가 필요할 수 있습니다. 분산 애플리케이션을 처리하는 경우 지리적으로 멀리 떨어진 거리로 인해 추가로 발생하는 통신 홉 또는 상태 복제 비용 때문에 대기 시간이 허용할 수 있는 한도를 초과할 수 있습니다. 이러한 상관 관계는 애플리케이션마다 다릅니다.

특히 소프트웨어 오류의 경우 스케일링하려는 서비스에 오류가 있을 수 있습니다. 이 경우 모든 인스턴스 간의 오류 상태에 상관관계가 존재하기 때문에 더 많은 복사본으로도 재해를 방지할 수 없게 됩니다.

작동 오류

서비스가 많은 중복성으로 전 세계에 스팬되더라도 여전히 재해 이벤트가 발생할 수 있습니다. 예를 들어 누군가가 실수로 서비스의 DNS 이름을 재구성하거나 서비스를 완전히 삭제할 수 있습니다.

한 가지 예로, 상태 저장 Service Fabric 서비스가 있으며 누군가가 해당 서비스를 실수로 삭제한 경우를 가정해 보겠습니다. 다른 완화 방법이 없다면 해당 서비스와 서비스의 모든 상태는 삭제된 상태가 됩니다. 이러한 유형의 작동 재해("oops")를 위해서는 일반적인 계획되지 않은 오류와는 다른 완화 방법 및 복구 단계가 필요합니다.

이러한 유형의 작동 오류를 방지하는 가장 좋은 방법은 다음과 같습니다.

  • 환경에 대한 작동 액세스 제한
  • 위험한 작업을 엄격하게 감사
  • 자동화 적용, 수동 또는 대역 외 변경 방지, 특정 변경을 적용하기 전에 실제 환경에 유효한지 검사
  • 파괴적인 작업이 "소프트"되도록 합니다. 소프트 작업은 즉시 적용되지 않거나 기간 내에 취소할 수 있습니다.

Service Fabric은 클러스터 작업에 역할 기반 액세스 제어를 제공하는 경우처럼 작동 오류를 방지하기 위한 메커니즘을 제공합니다. 그러나 이러한 작동 오류 대부분을 해결하려면 조직의 노력 및 기타 시스템이 필요합니다. Service Fabric은 작동 오류를 해결하기 위한 메커니즘을 제공합니다. 이 중에서 가장 주목할 만한 것이 상태 저장 서비스에 대한 백업 및 복원입니다.

오류 관리

Service Fabric의 목표는 오류를 자동으로 관리하는 것입니다. 그러나 일부 오류 유형을 처리하려면 서비스에 추가 코드가 있어야 합니다. 다른 유형의 오류는 안전 및 비즈니스 연속성 이유로 인해 자동으로 해결하지 ‘말아야’ 합니다.

단일 오류 처리

단일 컴퓨터는 모든 종류의 이유로 인해 실패할 수 있습니다. 전원 공급 장치, 네트워크 하드웨어 오류 등, 하드웨어로 인한 오류가 발생하기도 합니다. 다른 오류는 소프트웨어에서 나타납니다. 여기에는 운영 체제 및 서비스 자체의 오류가 포함됩니다. Service Fabric은 네트워크 문제로 인해 머신이 다른 머신에서 격리되는 경우를 포함하여 해당 유형의 오류를 자동으로 검색합니다.

서비스 유형에 관계 없이, 어떤 이유로든 코드의 단일 복사본이 실패할 경우 단일 인스턴스를 실행하면 해당 서비스에 대해 가동 중지가 발생합니다.

모든 단일 오류를 처리하기 위해 할 수 있는 가장 간단한 작업은 서비스를 기본적으로 2개 이상의 노드에서 실행하는 것입니다. 상태 비저장 서비스의 경우 InstanceCount가 1보다 큰지 확인합니다. 상태 비저장 서비스의 경우 TargetReplicaSetSize와 MinReplicaSetSize를 모두 3으로 설정하는 것이 최소 권장 사항입니다. 서비스 코드의 복사본을 더 많이 실행하면 서비스가 모든 단일 오류를 자동으로 처리할 수 있습니다.

조정된 오류 처리

계획되었거나 계획되지 않은 인프라 오류 및 변경이나 계획된 소프트웨어 변경으로 인해 클러스터에서 조정된 오류가 발생할 수 있습니다. Service Fabric은 조정된 오류가 발생하는 인프라 영역을 ‘장애 도메인’으로 모델링합니다. 조정된 소프트웨어 변경이 발생하는 영역은 ‘업그레이드 도메인’으로 모델링됩니다. 장애 도메인, 업그레이드 도메인 및 클러스터 토폴로지에 대한 자세한 내용은 클러스터 리소스 관리자를 사용하여 Service Fabric 클러스터 설명을 참조하세요.

기본적으로 Service Fabric은 서비스 실행 위치를 계획할 때 장애 및 업그레이드 도메인을 고려합니다. 기본적으로 Service Fabric은 계획되었거나 계획되지 않은 변경이 발생하는 경우에도 서비스를 계속 사용할 수 있도록 여러 장애 및 업그레이드 도메인에 걸쳐 서비스가 실행되도록 하려고 시도합니다.

예를 들어 전원 오류로 인해 동시에 랙에 있는 모든 머신에 오류가 발생하는 경우를 가정해 보겠습니다. 서비스의 여러 복사본이 실행되는 경우, 장애 도메인의 오류에 따른 여러 머신의 손실은 서비스에 대한 단일 오류의 또 다른 예에 불과합니다. 이 때문에 서비스의 고가용성을 보장하려면 반드시 장애 및 업그레이드 도메인을 관리해야 합니다.

Azure에서 Service Fabric을 실행하는 경우 장애 도메인과 업그레이드 도메인이 자동으로 관리됩니다. 다른 환경에서는 그러지 않을 수 있습니다. 온-프레미스에서 사용자의 고유 클러스터를 빌드하는 경우 장애 도메인 레이아웃을 올바르게 매핑 및 계획해야 합니다.

업그레이드 도메인은 소프트웨어가 동시에 업그레이드될 영역을 모델링하는 데 유용합니다. 이로 인해 업그레이드 도메인은 종종 계획된 업그레이드를 수행하는 동안 소프트웨어의 가동이 중단되는 경계도 정의합니다. Service Fabric 및 서비스의 업그레이드는 둘 다 동일한 모델을 따릅니다. 롤링 업그레이드, 업그레이드 도메인, 그리고 의도치 않은 변경이 클러스터와 서비스에 영향을 미치지 않도록 하는 Service Fabric 상태 모델에 대한 자세한 내용은 다음을 참조하세요.

Service Fabric Explorer에 제공된 클러스터 맵을 사용하여 클러스터의 레이아웃을 시각화할 수 있습니다.

Nodes spread across fault domains in Service Fabric Explorer

참고 항목

오류 영역 모델링, 롤링 업그레이드, 서비스 코드 및 상태의 여러 인스턴스 실행, 장애 및 업그레이드 도메인에 걸쳐 서비스가 실행되도록 보장하는 배치 규칙, 기본 제공 상태 모니터링은 Service Fabric이 일반적인 작동 문제 및 오류가 재해로 전환되지 않도록 하기 위해 제공하는 기능 중 ‘일부’에 불과합니다.

동시에 발생하는 하드웨어 또는 소프트웨어 오류 처리

지금까지는 단일 오류에 대해 이야기했습니다. 아시다시피 장애 및 업그레이드 도메인 간에 코드(및 상태)의 여러 복사본을 실행하도록 하는 것만으로도 상태 비저장 및 상태 저장 서비스를 전부 쉽게 처리할 수 있습니다.

여러 임의 오류가 동시에 발생할 수도 있습니다. 해당 오류는 실제 재해로 발전할 가능성이 높습니다.

상태 비저장 서비스

상태 비저장 서비스의 인스턴스 수는 실행되어야 하는 인스턴스의 원하는 수를 나타냅니다. 어떤 인스턴스라도 실패하거나 모든 인스턴스가 실패하면 Service Fabric이 다른 노드에서 대체 인스턴스를 자동으로 만들어 응답합니다. 서비스가 다시 원하는 인스턴스 수로 복구될 때까지 Service Fabric에서 대체 인스턴스를 계속 만듭니다.

예를 들어 상태 비저장 서비스의 InstanceCount 값이 -1이라고 가정합니다. 이 값은 클러스터의 각 노드에서 하나의 인스턴스가 실행되어야 함을 뜻합니다. 해당 인스턴스 중 일부가 실패하면 Service Fabric에서 서비스가 바람직한 상태가 아니라는 것을 감지하고 인스턴스가 누락된 노드에 인스턴스를 만들려고 시도합니다.

상태 저장 서비스

상태 저장 서비스에는 두 가지 유형이 있습니다.

  • 상태가 영구적인 상태 저장 서비스
  • 상태가 영구적이지 않은 상태 저장 서비스 (상태는 메모리에 저장됩니다.)

상태 저장 서비스의 오류 복구는 상태 저장 서비스의 유형, 서비스에 포함된 복제본 수 및 오류가 발생한 복제본 수에 따라 달라집니다.

상태 저장 서비스에서 들어오는 데이터는 복제본(주 복제본과 활성화 상태인 보조 복제본) 간에 복제됩니다. 대부분의 복제본이 데이터를 수신하는 경우 데이터는 ‘쿼럼’ 커밋된 것으로 간주됩니다. (5개의 복제본의 경우 3개는 쿼럼입니다.) 즉, 어느 시점에서든 최신 데이터가 있는 복제본의 쿼럼이 있을 수 있습니다. 복제본에 오류가 발생하는 경우(예를 들어 5개 중 2개라고 가정) 쿼럼 값을 사용하여 복구 가능 여부를 계산할 수 있습니다. (복제본 5개 중 나머지 3개는 여전히 작동하므로 하나 이상의 복제본에 완전한 데이터가 존재하게 됩니다.)

복제본의 쿼럼에 오류가 발생하는 경우 파티션이 ‘쿼럼 손실’ 상태에 있도록 선언됩니다. 파티션에 복제본 5개가 있다고 가정해 보겠습니다. 즉, 3개 이상의 복제본이 완전한 데이터를 갖게 됩니다. 복제본의 쿼럼(5개 중 3개)에 오류가 발생하는 경우 Service Fabric이 나머지 복제본(5개 중 2개)에 파티션을 복원하기에 충분한 데이터가 있는지 확인할 수 없습니다. Service Fabric이 쿼럼 손실을 감지하는 경우 파티션에 대한 추가 쓰기를 방지하고, 쿼럼 손실을 선언하고, 복제본의 쿼럼이 복원될 때까지 대기하는 것이 기본 동작입니다.

상태 저장 서비스에 재해가 발생했는지 여부를 확인하고 관리하는 작업은 다음 3단계로 진행됩니다.

  1. 쿼럼 손실 여부 확인

    쿼럼 손실은 상태 저장 서비스 복제본의 과반수가 동시에 가동 중단될 경우 선언됩니다.

  2. 쿼럼 손실이 영구적인지 여부 확인

    대부분의 경우 오류는 일시적입니다. 프로세스가 다시 시작되고, 노드가 다시 시작되고, 가상 머신이 다시 시작되고, 네트워크 파티션이 회복됩니다. 그러나 때에 따라 오류가 영구적일 수 있습니다. 오류가 영구적인지 여부는 상태 저장 서비스의 상태가 영구적인지 또는 메모리에만 유지되는지 여부에 따라 달라집니다.

    • 영구 상태가 아닌 서비스의 경우 쿼럼 이상의 복제본에 오류가 발생하면 즉시 영구 쿼럼 손실이 발생합니다. Service Fabric이 상태 저장 비영구 서비스에서 쿼럼 손실을 발견하면 (잠재적) 데이터 손실을 선언하여 3단계를 즉시 진행합니다. Service Fabric은 복제본이 복구되기를 기다려도 소용이 없다는 사실을 알고 있기 때문에 데이터 손실이 발생해도 작업을 계속 진행합니다. 복구하더라도 서비스의 비영구적인 특성 때문에 데이터가 손실됩니다.
    • 상태 저장 영구 서비스의 경우 복제본의 쿼럼 1개 이상에 오류가 발생하면 Service Fabric은 복제본이 복구되고 쿼럼을 복원하기를 기다리기 시작합니다. 이로 인해 서비스의 영향 받는 파티션(또는 "복제본 세트")에 대한 쓰기 동안 서비스가 중단됩니다. 그러나 일관성은 감소하지만 읽기는 계속 진행될 수 있습니다. 계속 진행하는 것은 잠재적인 데이터 손실 이벤트이며 다른 위험을 수반하게 되므로 Service Fabric이 쿼럼 복원을 기다리는 기본 시간의 양은 ‘무한’합니다. 즉, 관리자가 데이터 손실을 선언하는 조치를 취하지 않는 한 Service Fabric은 다음 단계로 진행되지 않습니다.

  3. 데이터가 손실되었는지 확인하고 백업에서 복원

    쿼럼 손실이 선언되면(자동으로 또는 관리자의 조치를 통해) Service Fabric과 서비스가 계속 진행해서 데이터가 실제로 손실되었는지 확인합니다. 또한 이 시점에 Service Fabric은 다른 복제본이 복구되지 않을 것이라는 사실도 알고 있습니다. 이것은 쿼럼 손실의 자체 해결을 더 이상 기다리지 않기로 했을 때 이미 결정된 사항이었습니다. 서비스에 대한 최선의 작업 과정은 중단된 후 특정 관리 개입을 기다리는 것입니다.

    Service Fabric은 데이터 손실이 ‘의심’될 때만 OnDataLossAsync 메서드를 호출합니다. Service Fabric은 이 호출이 최상의 나머지 복제본으로 전달되도록 합니다. 가장 많이 진행된 복제본이 여기에 해당됩니다.

    항상 데이터 손실이 ‘의심’된다고 말하는 이유는 쿼럼이 손실되었을 때 나머지 복제본이 주 복제본과 동일한 상태를 가지고 있을 수 있기 때문입니다. 그러나 비교할 상태가 없으면 Service Fabric 또는 운영자가 확인할 방법이 없습니다.

    그렇다면 OnDataLossAsync 메서드의 일반적인 구현은 어떤 작업을 수행할까요?

    1. OnDataLossAsync가 트리거한 구현 로그입니다. 또한 필요한 모든 관리 경고를 발생시킵니다.

    2. 일반적으로 구현이 일시 중지되고 추가 결정 및 수동 작업이 수행될 때까지 기다립니다. 백업을 사용할 수 있더라도 준비가 필요하기 때문입니다.

      예를 들어 서로 다른 서비스 2개가 정보를 조정하는 경우 복원이 발생할 때 해당 두 서비스에 필요한 정보가 일관되도록 하기 위해 해당 백업을 수정해야 할 수 있습니다.

    3. 종종 서비스에서 다른 원격 분석 또는 배출이 발생할 수 있습니다. 이 메타데이터는 다른 서비스 또는 로그에 포함될 수 있습니다. 백업에 없거나 해당하는 특정 복제본으로 복제되지 않은 주 복제본에서 수신되고 처리된 호출이 있는지 확인하기 위해 해당 정보를 사용해야 할 수 있습니다. 복원이 가능하게 하려면 먼저 해당 호출을 재생하거나 백업에 추가해야 할 수 있습니다.

    4. 구현은 나머지 복제본의 상태를 사용할 수 있는 모든 백업에 포함된 상태와 비교합니다. Service Fabric의 신뢰할 수 있는 컬렉션을 사용하는 경우 관련 작업에 사용할 수 있는 도구 및 프로세스가 있습니다. 목표는 복제본 내의 상태가 충분한지 또는 누락된 백업이 어느 것인지 확인하는 것입니다.

    5. 비교가 수행되고 필요에 따라 복원이 완료되면, 상태가 변경된 경우 서비스 코드는 true를 반환해야 합니다. 복제본이 해당 상태를 사용 가능한 최고 상태의 사본이라고 판단했으며 아무것도 변경하지 않은 경우 코드는 false를 반환합니다.

      true 값은 ‘나머지’ 복제본 중에 하나라도 해당 복제본과 일치하지 않을 수 있음을 나타냅니다. 이러한 상태는 삭제되며 이 복제본에서 다시 작성됩니다. false 값은 상태가 변경되지 않았으므로 다른 복제본이 상태를 그대로 유지할 수 있음을 나타냅니다.

서비스가 프로덕션에 배포되기 전에 서비스 작성자가 잠재적인 데이터 손실 및 오류 시나리오를 연습해 보는 것이 매우 중요합니다. 데이터 손실 가능성을 방지하기 위해서는 정기적으로 모든 상태 저장 서비스의 상태를 지역 중복 저장소로 백업하는 것이 중요합니다.

또한 상태를 복원하는 능력을 갖추고 있어야 합니다. 여러 가지 다양한 서비스의 백업이 서로 다른 시간에 수행되므로 복원 후에 서비스가 서로 일관되게 보이는지도 확인해야 합니다.

예를 들어 한 서비스가 숫자를 생성 및 저장한 후 이 숫자를 저장하는 또 다른 서비스로 전송하는 상황을 가정해 보겠습니다. 복원 후에 두 번째 서비스에는 해당 숫자가 있지만 첫 번째 서비스에는 없다는 것을 확인할 수 있습니다. 해당 백업에 이 작업이 포함되어 있지 않기 때문입니다.

나머지 복제본이 데이터 손실 시나리오에서 계속 유지되기에 충분하지 않으며 원격 분석 또는 배출을 통해 서비스 상태를 다시 생성할 수 없는 경우, 백업 빈도에 따라 가능한 최상의 RPO(복구 지점 목표)가 결정됩니다. Service Fabric은 백업에서 복원해야 하는 영구 쿼럼 및 데이터 손실을 비롯한 다양한 오류 시나리오를 테스트하기 위한 여러 가지 도구를 제공합니다. 해당 시나리오는 오류 분석 서비스를 통해 관리되는 Service Fabric의 테스트 용이성 도구의 일부로 포함됩니다. 관련 도구와 패턴에 대한 자세한 내용은 오류 분석 서비스 소개를 참조하세요.

참고 항목

시스템 서비스에 쿼럼 손실이 발생할 수도 있습니다. 그 영향은 문제가 발생한 서비스에 따라 다릅니다. 예를 들어 장애 조치(failover) 관리자 서비스의 쿼럼 손실은 새 서비스 만들기 및 장애 조치를 차단하는 한편, 명명 서비스의 쿼럼 손실은 이름 확인에 영향을 줍니다.

Service Fabric 시스템 서비스는 상태 관리용 서비스와 동일한 패턴을 따르지만, 서비스를 쿼럼 손실에서 잠재적인 데이터 손실로 전환하려고 시도하는 것은 바람직하지 않습니다. 대신 상황에 맞는 솔루션을 찾기 위한 지원을 요청하는 것이 권장 사항입니다. 일반적으로 다운된 복제본이 돌아올 때까지 대기하는 것이 좋습니다.

쿼럼 손실 문제 해결

일시적인 오류로 인해 복제본이 일시적으로 다운될 수 있습니다. Service Fabric이 복제본을 복원하려고 시도하는 동안 잠시 대기합니다. 예상한 기간보다 오래 복제본이 다운되어 있으면 다음 문제 해결 작업을 수행합니다.

  • 복제본이 충돌하고 있을 수 있습니다. 복제본 수준 상태 보고서와 애플리케이션 로그를 확인합니다. 크래시 덤프를 수집하고 필요한 작업을 수행하여 복구합니다.
  • 복제본 프로세스가 응답하지 않을 수 있습니다. 애플리케이션 로그를 검사하여 관련 문제를 확인합니다. 프로세스 덤프를 수집하고 응답하지 않는 프로세스를 중지합니다. Service Fabric이 교체 프로세스를 생성하고 복제본을 다시 복원하려고 시도합니다.
  • 복제본을 호스트하는 노드가 다운되었을 수 있습니다. 기본 가상 머신을 다시 시작하여 노드를 실행합니다.

때에 따라 복제본을 복구할 수 없을 수 있습니다. 예를 들어 드라이브에 오류가 발생했거나 머신이 물리적으로 응답하지 않는 경우입니다. 이 경우 Service Fabric이 복제본 복구를 기다리지 않도록 지시해야 합니다.

서비스를 온라인으로 전환하는 과정에서 잠재적 데이터 손실이 허용되지 않는 경우 해당 방법을 사용하지 ‘마세요’. 이 경우 물리적 머신 복구에 모든 노력을 기울여야 합니다.

다음 작업으로 인해 데이터가 손실될 수 있습니다. 따르기 전에 확인하세요.

참고 항목

특정 파티션에만 적용되는 방식 외에 다른 방식으로 해당 방법을 사용하는 것은 ‘절대’ 안전하지 않습니다.

  • Repair-ServiceFabricPartition -PartitionId 또는 System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) API를 사용합니다. 이 API를 사용하면 쿼럼 손실에서 옮겨서 잠재적 데이터 손실로 전환할 파티션의 ID를 지정할 수 있습니다.
  • 클러스터에 서비스를 쿼럼 손실 상태로 전환시키는 오류가 자주 발생하며 잠재적 ‘데이터 손실이 허용’되는 경우, 적절한 QuorumLossWaitDuration 값을 지정하면 서비스에서 자동으로 복구하는 데 도움이 될 수 있습니다. Service Fabric이 주어진 QuorumLossWaitDuration 값(기본값은 무한)만큼 기다린 후 복구를 수행합니다. 이 방법은 예기치 않은 데이터 손실을 야기할 수 있으므로 권장하지 ‘않습니다’.

Service Fabric 클러스터의 가용성

일반적으로 Service Fabric 클러스터는 단일 실패 지점이 없는 고도로 분산된 환경입니다. 한 노드에서 발생한 오류는 클러스터의 가용성 또는 안정성 문제를 유발하지 않습니다. 이것은 기본적으로 Service Fabric 시스템 서비스가 앞서 제공된 것과 동일한 지침을 따르기 때문입니다. 즉, 기본적으로 서비스는 항상 3개 이상의 복제본과 함께 실행되며, 상태 비저장 시스템 서비스는 모든 노드에서 실행됩니다.

기본 Service Fabric 네트워킹 및 오류 감지 계층은 완전히 분산되어 있습니다. 대부분의 시스템 서비스는 클러스터의 메타데이터에서 다시 구축될 수 있고 다른 위치에서 해당 상태를 다시 동기화하는 방법을 알고 있습니다. 시스템 서비스가 앞서 설명된 것과 같은 쿼럼 손실 상황에 처할 경우 클러스터의 가용성이 손상될 수 있습니다. 이러한 경우 클러스터에서 업그레이드를 시작하거나 새 서비스를 배포하는 등의 특정 작업을 수행할 수 없지만 클러스터 자체는 계속 실행됩니다.

작동을 지속하기 위해 시스템 서비스에 대한 쓰기가 필요한 경우만 아니면 해당 상태에서 실행 중인 클러스터의 서비스도 계속 실행됩니다. 예를 들면 장애 조치 관리자에 쿼럼 손실이 발생해도 모든 서비스가 계속 실행됩니다. 그러나 오류가 발생한 서비스는 자동으로 다시 시작할 수 없습니다. 이 경우에는 장애 조치 관리자가 개입해야 하기 때문입니다.

데이터 센터 또는 Azure 지역 오류

드문 경우지만 전원 또는 네트워크 연결의 손실로 인해 물리적 데이터 센터를 일시적으로 사용할 수 없게 될 수 있습니다. 이 경우 해당 데이터 센터 또는 Azure 지역의 Service Fabric 클러스터 및 서비스를 사용할 수 없게 됩니다. 그러나 사용자 데이터는 보존됩니다.

Azure에서 실행 중인 클러스터의 경우 Azure 상태 페이지의 중단에 대한 업데이트를 확인할 수 있습니다. 가능성이 매우 낮지만 물리적 데이터 센터가 부분적으로나 완전히 소멸하는 이벤트가 발생하면 해당 데이터 센터에서 호스트되는 Service Fabric 클러스터 또는 내부 서비스가 손실될 수 있습니다. 이 손실에는 해당 데이터 센터 또는 하위 지역 외부에서 백업되지 않은 모든 상태가 포함됩니다.

단일 데이터 센터 또는 하위 지역의 영구적이거나 지속적인 오류를 해결하는 데에는 몇 가지 다른 전략이 있습니다.

  • 별도의 Service Fabric 클러스터를 여러 하위 지역에서 실행하고 해당 환경 사이에서 몇 가지 장애 조치 및 장애 복구(failback) 메커니즘을 활용합니다. 이러한 종류의 다중 클러스터 활성/활성 또는 활성/수동 모델에는 추가적인 관리 및 연산 코드가 필요합니다. 이뿐 아니라 이 모델을 사용하려면 하나의 데이터 센터 또는 하위 지역에서 오류가 발생했을 때 다른 데이터 센터나 하위 지역에서 서비스를 사용할 수 있도록 데이터 센터 또는 하위 지역 내의 서비스에 대한 백업 조정이 필요합니다.

  • 여러 데이터 센터에 걸쳐 있는 단일 Service Fabric 클러스터를 실행합니다. 이 전략을 활용하기 위해 지원되는 최소 구성은 데이터 센터 3개입니다. 자세한 내용은 가용성 영역에 Service Fabric 클러스터 배포를 참조하세요.

    이 모델에는 추가 설정이 필요합니다. 하지만 이 모델의 장점은 데이터 센터의 오류가 재해에서 일반 오류로 변환된다는 것입니다. 이러한 오류는 단일 하위 지역 내에서 클러스터에 작동하는 메커니즘에 의해 처리될 수 있습니다. 장애 도메인, 업그레이드 도메인, Service Fabric 배치 규칙은 일반 오류를 허용할 수 있도록 워크로드를 분산시킵니다.

    이 유형의 클러스터에서 서비스를 작동하는 데 도움이 되는 정책에 대한 자세한 내용은 Service Fabric 서비스에 대한 배치 정책을 참조하세요.

  • 독립 실행형 모델을 사용하여 여러 지역에 걸쳐 있는 단일 Service Fabric 클러스터를 실행합니다. 권장되는 지역 수는 3개입니다. 독립 실행형 Service Fabric 설정에 대한 자세한 내용은 독립형 클러스터 만들기를 참조하세요.

클러스터 오류로 발전하는 임의 오류

Service Fabric에는 ‘시드 노드’라는 개념이 있습니다. 이러한 노드는 기본 클러스터의 가용성을 유지 관리하는 노드입니다.

시드 노드는 다른 노드와 임대 관계를 설정하고 특정 종류의 오류 중에 결정적인 요인으로 작용하여 클러스터의 작동 상태를 유지하는 데 도움을 줍니다. 임의 오류로 인해 클러스터의 시드 노드 과반수가 제거된 후 빠르게 복구되지 않으면 클러스터는 자동으로 종료됩니다. 그러면 클러스터가 실패합니다.

Azure에서 Service Fabric 리소스 공급자는 Service Fabric 클러스터 구성을 관리합니다. 기본적으로 리소스 공급자는 ‘주 노드 유형’의 장애 및 업그레이드 도메인 전반에 시드 노드를 배포합니다. 주 노드 유형이 Silver 또는 Gold 내구성으로 표시된 경우 주 노드 유형에서 스케일링하거나 수동으로 제거하여 시드 노드를 제거할 때 클러스터는 주 노드 유형의 사용 가능한 용량에서 다른 비 시드 노드의 승격을 시도합니다. 주 노드 유형에 필요한 클러스터 안정성 수준보다 사용 가능한 용량이 적으면 이 시도가 실패합니다.

독립 실행형 Service Fabric 클러스터 및 Azure 모두에서 주 노드 유형은 시드를 실행하는 노드입니다. 주 노드 유형을 정의할 때 Service Fabric은 각 시스템 서비스에 대해 최대 9개의 시드 노드와 7개의 복제본을 만들어 제공되는 노드 수를 자동으로 활용합니다. 해당 복제본의 과반수에서 임의 오류가 동시에 발생하면 시스템 서비스는 쿼럼 손실 상태가 됩니다. 시드 노드 과반수가 손실되면 클러스터는 즉시 종료됩니다.

다음 단계