구성은 상태 저장 서비스의 파티션에 대한 복제본 및 해당 역할로 정의됩니다.
재구성은 하나의 구성을 다른 구성으로 이동하는 프로세스입니다. 상태 저장 서비스의 파티션에 대한 복제본 집합을 변경합니다. 이전 구성을 이전 구성(PC)이라고 하며 새 구성을 CC(현재 구성)라고 합니다. Azure Service Fabric의 재구성 프로토콜은 일관성을 유지하고 복제본 집합을 변경하는 동안 가용성을 유지합니다.
장애 조치(failover) 관리자는 시스템의 다양한 이벤트에 대한 응답으로 재구성을 시작합니다. 예를 들어 주 복제본이 실패하면 활성 보조 복제본을 주 복제본으로 승격하기 위한 재구성이 시작됩니다. 또 다른 예는 노드를 업그레이드하기 위해 주 노드를 다른 노드로 이동해야 할 수 있는 애플리케이션 업그레이드에 대한 응답입니다.
재구성 형식
재구성은 다음 두 가지 형식으로 분류할 수 있습니다.
기본 설정이 변경되는 경우 재구성:
- 장애 조치: 장애 조치는 실행 중인 주 복제본의 실패에 대한 응답으로 재구성하는 것입니다.
- SwapPrimary: 교환은 Service Fabric이 일반적으로 부하 분산 또는 업그레이드에 대한 응답으로 실행 중인 주 데이터베이스를 한 노드에서 다른 노드로 이동해야 하는 재구성입니다.
기본 구성이 변경되지 않는 재구성입니다.
재구성 단계
재구성은 여러 단계로 진행됩니다.
단계0: 이 단계는 현재 주 복제본이 해당 상태를 새 주 복제본으로 전송하고 활성 보조 복제본으로 전환하는 스왑-기본 재구성에서 발생합니다.
1단계: 이 단계는 주 복제본이 변경되는 재구성 중에 발생합니다. 이 단계에서 Service Fabric은 현재 복제본 중에서 올바른 주 복제본을 식별합니다. 새 주가 이미 선택되었으므로 스왑-주 재구성 중에는 이 단계가 필요하지 않습니다.
2단계: 이 단계에서 Service Fabric은 현재 구성의 복제본 대부분에서 모든 데이터를 사용할 수 있도록 합니다.
내부용으로만 사용할 수 있는 몇 가지 다른 단계가 있습니다.
중지된 재구성
재구성은 다양한 이유로 중단 될 수 있습니다. 몇 가지 일반적인 이유는 다음과 같습니다.
- 다운된 복제본: 일부 재구성 단계에서는 구성의 복제본 중 과반수가 가동 상태여야 합니다.
- 네트워크 또는 통신 문제: 재구성에는 서로 다른 노드 간의 네트워크 연결이 필요합니다.
- API 오류: 재구성 프로토콜을 사용하려면 서비스 구현이 특정 API를 완료해야 합니다. 예를 들어 신뢰할 수 있는 서비스에서 취소 토큰을 적용하지 않으면 SwapPrimary 재구성이 중단됩니다.
System.FM, System.RA 및 System.RAP와 같은 시스템 구성 요소의 상태 보고서를 사용하여 재구성이 중단된 위치를 진단합니다. 시스템 상태 보고서 페이지에서는 이러한 상태 보고서를 설명합니다.
다음 단계
Service Fabric 개념에 대한 자세한 내용은 다음 문서를 참조하세요.