탄력성을 위한 모범 사례

이 항목에서는 Oracle Blockchain Platform의 엔터프라이즈 구성 인스턴스의 단일 VM(가상 머신)이 유지 관리를 위해 오프라인으로 전환되거나 예기치 않게 실패하는 경우 작업을 계속 유지하는 모범사례를 설명합니다.

다음 단계는 엔터프라이즈 구성(표준 구성 아님)을 기반으로 하는 Oracle Blockchain Platform의 인스턴스에만 적용됩니다. 또한 이 지침은 다음 배포 모델에만 적용됩니다.

• 단일 설립자 조직
• 하나 이상의 참가자 조직이 있는 설립자

표준 구성을 기반으로 하는 Oracle Blockchain Platform 인스턴스는 단일 VM에서 모든 구성요소(피어, 주문자 및 플랫폼 서비스)를 실행하므로 VM에 장애가 발생하거나 유지보수를 위해 정지해야 하는 경우 전체 인스턴스를 사용할 수 없게 됩니다. 가용성 도메인 또는 장애 도메인 간 격리는 없습니다. 운용 환경에 대해 표준 구성을 기반으로 인스턴스를 사용하지 마십시오.

대신 운영 환경에 대한 엔터프라이즈 구성을 기반으로 인스턴스를 사용하십시오. 이러한 인스턴스는 Hyperledger Fabric 구성 요소의 독립적인 확장과 더 높은 용량 구성을 제공합니다. 엔터프라이즈 구성 인스턴스는 피어, 주문자 및 플랫폼 구성요소를 가용성 도메인 및 장애 도메인 간에 자동으로 분산하여 인프라 수준의 장애 격리를 제공합니다. 이 동작을 활용하고 고가용성을 보장하려면 다음 절에 설명된 모범 사례를 사용합니다.

보증 정책

단일 설립자 조직이 있는 네트워크의 경우 사용 가능한 모든 피어가 OR('Founder.member') 또는 OutOf(1, 'Founder.member')과 같은 트랜잭션을 보증할 수 있도록 하는 보증 정책을 사용합니다. 설립자 조직에 대해 두 개 이상의 피어를 배치합니다.

설립자 및 참가자 조직이 한 명인 네트워크의 경우 일반적으로 OutOf(1, 'Founder.member', 'Participant1.member') 정책을 사용할 수 있습니다. 더 엄격한 구성의 경우 중복성이 있는 경우에만 OutOf(2, 'Founder.member', 'Participant1.member')를 사용할 수 있습니다. 두 조직에 충분한 피어 중복성이 없는 경우 AND('Founder.member', 'Participant1.member')과 같은 엄격한 정책을 사용하지 마십시오.

자세한 내용은 배서 정책 지정을 참조하십시오.

피어 배포

조직당 피어를 두 개 이상 배치합니다. Oracle Blockchain Platform은 가용성 도메인 및 장애 도메인에 피어를 자동으로 배포하여 VM 장애 발생 후에도 한 개 이상의 피어를 계속 사용할 수 있도록 합니다.

개인 정보 수집

개인 데이터 수집을 사용하는 경우 피어 필요 값(requiredPeerCount)을 하나 이상으로 설정하고 개인 데이터 수집 정의에서 최대 피어 수 값(maxPeerCount)을 2개 이상으로 설정합니다. 두 개 이상의 피어가 각 개인 데이터 수집의 멤버이고 개인 데이터가 두 개 이상의 피어에 걸쳐 커밋되도록 합니다. 피어 필요 값은 트랜잭션 제안이 완료된 것으로 간주되기 전에 개인 데이터를 성공적으로 수신해야 하는 최소 피어 수(보증 피어 제외)입니다.

조직 간 개인 데이터 수집의 경우 필요한 피어 수를 단일 조직의 피어 수보다 크게 구성하고 여러 조직 및 VM에 걸쳐 분배를 보장합니다.

자세한 내용은 개인 데이터 수집 추가를 참조하십시오.

래프트 주문 서비스

기본 3노드 래프트 주문 서비스를 사용합니다. Oracle Blockchain Platform은 주문 서비스가 단일 노드 장애를 처리할 수 있도록 가용성 도메인 및 장애 도메인에 주문자를 배포합니다.

앵커 피어

여러 조직이 있는 네트워크에서 조직당 하나 이상의 앵커 피어를 구성합니다. 복원성을 향상시키려면 조직당 앵커 피어를 두 개 이상 구성하십시오. 앵커 피어는 네트워크에 둘 이상의 Oracle Blockchain Platform 조직 인스턴스가 존재할 때만 필요합니다. 서로 다른 조직에서 gossip 기반 통신 및 피어 검색을 사용할 수 있기 때문입니다.

자세한 내용은 앵커 피어 추가을 참조하십시오.

체인코드 배포

피어를 사용할 수 없는 경우 연속성을 보장하려면 조직당 두 개 이상의 피어에 체인코드를 설치하고 승인하십시오. 개인 정보 보호 요구 사항이 허용하는 경우 이러한 배포를 네트워크의 Oracle Blockchain Platform 인스턴스에 분산시킬 수 있습니다.

클라이언트 연결

특정 피어에 래치되지 않도록 클라이언트 응용 프로그램을 구성합니다. 대신, 기본 클라이언트 라이브러리가 피어 선택을 처리하도록 허용합니다.

폴백 상태 데이터베이스

상태 데이터베이스는 피어가 조인되는 모든 채널에 대해 각 피어에 저장됩니다. VM이 실패하면 피어가 복원될 때까지 해당 피어의 로컬 상태 데이터베이스를 사용할 수 없게 됩니다. Oracle Blockchain Platform은 외부 Oracle Database가 폴백(보조) 상태 데이터베이스로 작동하는 하이브리드 상태 데이터베이스 모델을 지원합니다. 폴백 상태 데이터베이스가 사용으로 설정된 경우 상태 데이터는 필요에 따라 기본 상태 데이터베이스로 인계할 수 있는 데이터베이스의 피어 VM 외부에 유지되므로 지속성과 복구가 향상됩니다.

복원성을 향상시키기 위해 이 기능을 사용하려면 다음 단계를 수행하십시오.

• 운용 작업 로드 또는 중요한 작업 로드에 대해 폴백 상태 데이터베이스 활성화
• 피어 VM과 독립적으로 Oracle Database를 배치합니다.
• 고가용성을 위해 Oracle Database를 구성합니다.

이러한 단계를 수행하면 상태 데이터가 단일 VM의 수명 주기에 연결되지 않도록 할 수 있습니다. 폴백 상태 데이터베이스는 단일 VM이 실패하는 시나리오에 대해 피어 중복성으로 보완됩니다.

자세한 내용은 Create the Fallback State Database를 참조하십시오.