월간, 블록체인

만약 지난 Identity 문서를 읽으셨다면, PKI가 어떻게 인증가능한 Identity를 신뢰 사슬을 통해 제공하는지 배우셨을 겁니다.

이제, 이러한 Identity가 어떻게 블록체이 네트워크 내부의 신뢰 받는 사용자로서 나타나 지기위해서 사용될 수 있는지에 대해서 배워보시겠습니다.

이 곳이 Membership Service Provider(MSP)가 활동은 시작하는 영역입니다. MSP는 어떤 루트 CA나 중간 CA가 신뢰 도메인의 사용자를 정의하기 위해서 신뢰받고 있는지를 구별해냅니다.

MSP는 사용자 identity 목록을 만듦으로서 또는 어떤 CA가 사용자의 유효한 Identity에 발급 권한이 있음을 앎으로서 , 또는 가장 일반적인 케이스일 경우 둘의 조합으로 구별해냅니다.

MSP의 힘은 누가 네트워크 참여자인지 또는 채널의 사용자 인지에 대한 단순한 목록을 만드는 정도는 뛰어넘습니다.

MSP는 일정 범위 안에서 또는 MSP가 대표하는 조직(트러스트 도메인)(예 : MSP 관리자, 조직 하위 구성원)에서 액터가 역할을 수행 할 수도 있는 특별한 역할을 식별할 수 있습니다.

그리고 또한 MSP는 네트워크나 채널 문맥 속에 접근 권한을 규정하기 위한 기반을 구성합니다.(예: 채널 관리자, 독자, 작가)

MSP의 설정은 모든 채널에 알려지고, 이 알려진 채널은 해당하는 조직에 참여하는 사용자입니다.(channel MSP의 형태로)

피어, Orderer, 클라이언트는 또한 채널 밖의 문맥에서 조직 구성원의 메시지를 인증하기 위해서 로컬 MSP 인스턴스를 유지합니다.(ILocal MSP로 알려진)

게다가, MSP는 이미 폐지된 Identity의 목록 인증을 허가합니다.(우리는 Identity 문서에서 이미 다루었지만, 이 프로세스가 어떻게 MSP로 넓혀지는지를 설명하겠습니다.)

우리는 로컬 그리고 채널 MSP에 대해서 잠시동안 조금 더 많은 내용을 설명하겠습니다. 지금부터 일반적인 상황에 MSP가 작동하는지를 설명하겠습니다.

MSP를 조직에 연결하기

조직은 구성원의 관리된 그룹이고, 다국적 기업에서 작은 꽃집까지 될 수 있는 하나의 그룹입니다.

조직에서 가장 중요한 것은 단일 MSP 이하의 구성원을 관리합니다.

이것은 우리가 나중에 설명할 X.509 인증 안에서의 조직 개념과는 다르다는 것을 주의하셔야 됩니다.

조직과 그 조직의 MSP 사이의 배타적인 관계는 조직 이후의 MSP의 이름 짓는 것을 더욱 민감하게 만듭니다.

여러분은 대부분의 정책 설정 안에 관습을 찾으실 수 있을 것입니다. 예를 들자면, 조직 org1은 MSP에선 org1-msp로 불리울 수 있습니다.

몇몇 경우에 조직은 다양한 멤버십 그룹을 요구할 수 있습니다. 예를 들면, 채널이 매우 다르게 다양한 멤버십 그룹에 요구하는 것과 같습니다.

이러한 경우에 다양한 MSP를 가지는 것이 일리가 있고, 그들을 각각 ORG2-MSP-NATIONAL, ORG2-MSP-GOVERNMENT와 같이

ORG2 안에 각각 다른 신뢰 멤버십 루트를 National 판매량 채널과 Govenment 규제 채널로 나누어 반영하는 하는 것은 일리가 있습니다.

조직을 위한 두 개의 다른 MSP 입니다. 첫 번째 설정은 MSP와 조직의 전형적인 관계를 보여줍니다. 단일 MSP는 조직 구성원의 리스트를 정의합니다.

두 번째 설정은, 각기 다른 MSP가 national, international, government 소속 조직적인 그룹을 대표하는 것에 사용됩니다.

조직적인 단위와 MSP

조직은 때론 여러 조직 단위(Organizational Unit; OU)로 나뉘며 각 조직 단위에는 특정한 책임에 대한 집합이 있습니다.

예를 들자면, ORG1 조직에서 이러한 개별 영업 방침을 반영하기 위해 조직 단위 ORG1-MANUFACTURER과 ORG1-DISTRIBUTION 조직 단위를 둘 수 있습니다.

CA가 X.509 인증을 발급하면, ou라는 인증서의 필드는 ID가 속한 사업부를 지정하게 됩니다.

OU가 블록체인 네트워크의 구성원으로 간주되는 조직의 부분을 제어하는 것에 있어서 어떤 방식으로 도움이 되는 지 차후에 알 수 있습니다.

예를 들어 ORG1-MANUFACTURING 조직 단위의 ID만 채널에 접근 할 수 있지만 ORG1-DISTRIBUTION은 채널에 접근할 수 없습니다.

마지막으로 조직 단위의 약간의 잘못된 사용일 수 있지만 컨소시엄으로 서로 다른 조직에서 서로를 구별하기 위해서 사용 할 수 있습니다.

이러한 경우에 서로 다른 조직에서는 신뢰 루트에 대해 동일한 루트 CA와 중간 CA를 사용하지만 OU의 각각 조직원의 구성원을 식별할 수 있도록 필드를 적절하게 할당합니다.

차후엔 이를 달성하기 위한 MSP 구성 방법도 알아보겠습니다.

로컬 및 채널 MSP

MSP는 채널 구성 ( 채널 MSP )과 배우의 전제 ( 로컬 MSP ) 의 로컬에서 Blockchain 네트워크의 두 위치에 나타납니다 . 노드 (피어 또는 발주자) 및 사용자 (SDK를 사용하는 CLI 또는 클라이언트 응용 프로그램을 사용하는 관리자 )에 대해 정의 된 로컬 MSP 모든 노드와 사용자는 로컬 MSP를 정의해야합니다 . 그 수준에서 관리 권한이나 참여 권한을 가진 사람과 채널 컨텍스트 (예 : 동료 조직의 관리자)를 정의합니다.

대조적으로 채널 MSP는 채널 수준에서 관리 및 참여 권한을 정의합니다 . 채널에 참여하는 모든 조직은 정의 된 MSP가 있어야합니다. 채널의 피어 및 Orderer는 모두 채널 MSP에서 동일한보기를 공유하므로 채널 참여자를 올바르게 인증 할 수 있습니다. 즉, 조직이 채널에 가입하고자하는 경우 조직 구성원에 대한 신뢰 체인을 포함하는 MSP를 채널 구성에 포함시켜야합니다. 그렇지 않으면이 조직의 신원에서 비롯된 트랜잭션이 거부됩니다.

여기에서 로컬 및 채널 MSP 간의 주요 차이점은 어떻게 작동하는지가 아니라 해당 범위 입니다.

로컬 및 채널 MSP. 각 피어의 신뢰 도메인 (예 : 조직)은 피어의 로컬 MSP (예 : ORG1 또는 ORG2)에 의해 정의됩니다. 채널에서 조직의 대표는 조직의 MSP를 채널에 포함시킴으로써 성취됩니다. 예를 들어,이 그림의 채널은 ORG1과 ORG2에 의해 관리됩니다. 비슷한 원리가 네트워크, Orderer및 사용자에게 적용되지만, 여기서는 설명의 편의를 위해 여기에 표시되지 않습니다.

로컬 MSP는 적용 대상 노드 또는 사용자의 파일 시스템에서만 정의 됩니다. 따라서 물리적 및 논리적으로 노드 나 사용자별로 하나의 로컬 MSP 만 있습니다. 그러나 채널 MSP는 채널의 모든 노드에서 사용할 수 있으므로 구성시 채널에 한 번 논리적으로 정의됩니다. 그러나 채널 MSP는 채널의 모든 노드의 파일 시스템에서 인스턴스화되고 컨센서스를 통해 동기화 된 State로 유지됩니다 . 따라서 각 노드의 로컬 파일 시스템에 각 채널 MSP의 사본이있는 반면, 논리적으로 채널 MSP는 채널이나 네트워크에 상주하며 유지 관리됩니다.

위 그림에서와 같이 블록 체인 관리자가 스마트 계약을 설치하고 인스턴스화 할 때 발생하는 상황을 확인하여 로컬 및 채널 MSP를 사용하는 방법을 확인하는 것이 도움이 될 수 있습니다 .

관리자 B는 RCA1에 자신의 로컬 MSP에 의해 발행되고 저장된 ID로 피어에 연결합니다 . 때 B는 피어에 스마트 계약을 설치하려고, 피어는 로컬 MSP를 확인 ORG1-MSP의 신원을 확인하기 위해, B는 ORG1의 진정한 구성원입니다. 성공적으로 확인하면 설치 명령이 성공적으로 완료됩니다. 이어서 B는 채널에서 스마트 계약을 인스턴스화하려고합니다. 이는 채널 운영이므로 채널의 모든 조직이 동의해야합니다. 따라서 피어는이 명령을 성공적으로 커밋하기 전에 채널의 MSP를 확인해야합니다. (다른 일도 일어나야하지만 지금은 위에 집중해야합니다.)

채널 자체가 논리적 구성인 것처럼 채널 MSP를 관찰 할 수 있습니다 . 채널 org 동료의 로컬 파일 시스템에서 인스턴스화되고 관리되는 경우에만 물리적으로됩니다.

MSP 수준

채널 및 로컬 MSP 사이의 분리는 피어 또는 발주자 노드와 같은 로컬 리소스 및 채널 또는 네트워크 수준에서 작동하는 원장, 스마트 계약 및 컨소시엄과 같은 채널 리소스를 관리하는 조직의 요구를 반영합니다. 그것은 다른에있는 이러한 MSP를 생각하는 것이 도움이 수준 으로, 네트워크 관리 문제에 관한 높은 수준에서 MSP를 하면서 민간 자원의 관리를위한 낮은 수준의 핸들 정체성에 MSP가 . MSP는 모든 관리 수준에서 필수적입니다. 즉, 네트워크, 채널, 피어, Orderer 및 사용자에 대해 정의해야합니다.

MSP 레벨. 피어 및 발주자에 대한 MSP는 로컬이며, 채널의 MSP (네트워크 구성 채널 포함)는 해당 채널의 모든 참가자에게 공유됩니다. 이 그림에서 네트워크 구성 채널은 ORG1에 의해 관리되지만 다른 응용 프로그램 채널은 ORG1 및 ORG2에 의해 관리 될 수 있습니다. 피어는 ORG2의 구성원이며 ORG2가 관리하지만 ORG1은 그림의 순서를 관리합니다. ORG1은 RCA1의 신원을 신뢰하지만 ORG2는 RCA2의 신원을 신뢰합니다. 이들은 관리 구성표로서 누가 이러한 구성 요소를 관리 할 수 ​​있는지 반영합니다. 따라서 ORG1이 네트워크를 관리하는 동안 ORG2.MSP는 네트워크 정의에 존재합니다.

• 네트워크 MSP : 네트워크 의 구성은 참가자 조직 MSP를 정의하여 네트워크의 구성원과 관리 작업 (예 : 채널 만들기)을 수행 할 권한이있는 구성원을 정의합니다.
• 채널 MSP : 채널에서 회원의 MSP를 별도로 유지 관리하는 것이 중요합니다. 채널은 조직의 특정 집합간에 사적인 통신을 제공하며 차례로 관리를 제어합니다. 채널의 MSP와 관련하여 해석되는 채널 정책은 채널에 대한 특정 작업 (예 : 조직 추가 또는 체인 코드 인스턴스 생성)에 참여할 수있는 권한을 가진 사용자를 정의합니다. 채널을 관리 할 수있는 권한과 네트워크 구성 채널 (또는 다른 채널)을 관리 할 수있는 권한 간에는 필요한 관계가 없습니다. 관리 권한은 관리 대상 범위 내에 존재합니다 (규칙이 다르게 작성되지 않은 경우 - ROLE아래 속성 에 대한 설명 참조).
• 피어 MSP : 이 로컬 MSP는 각 피어의 파일 시스템에 정의되며 각 피어에 대해 단일 MSP 인스턴스가 있습니다. 개념적으로 채널 MSP와 정확히 동일한 기능을 수행하지만, 정의 된 피어에만 적용된다는 제한이 있습니다. 피어의 로컬 MSP를 사용하여 권한 부여를 평가하는 작업의 예는 피어 전제에 체인 코드를 설치하는 것입니다.
• 발주자 MSP : 피어 MSP와 마찬가지로 발주자 로컬 MSP도 노드의 파일 시스템에 정의되어 있으며 해당 노드에만 적용됩니다. 피어 노드와 마찬가지로 Orderer는 단일 조직에서 소유하므로 신뢰할 수있는 액터 또는 노드를 나열하는 단일 MSP가 있습니다.

MSP 구조

지금까지 MSP의 가장 중요한 두 요소는 해당 조직에서 액터 또는 노드의 구성원을 설정하는 데 사용 된 (루트 또는 중간) CA의 사양입니다. 그러나 멤버십 기능을 보조하기 위해이 두 가지 요소와 함께 사용되는 요소가 더 많습니다.

위의 그림은 로컬 MSP가 로컬 파일 시스템에 저장되는 방법을 보여줍니다. 비록 채널 MSP가 정확히 이런 방식으로 물리적으로 구조화되어 있지는 않지만, 그것들에 대해서 생각하는 것은 여전히 ​​유용한 방법입니다.

보시다시피 MSP에는 9 가지 요소가 있습니다. MSP 이름이 MSP 구성의 다른 요소를 나타내는 각 하위 폴더와 함께 루트 폴더 이름 인 디렉터리 구조에서 이러한 요소를 생각하는 것이 가장 쉽습니다.

이 폴더에 대해 좀 더 자세하게 설명하고 중요한 이유를 알아 보겠습니다.

• 루트 CA : 이 폴더는이 MSP가 나타내는 조직에서 신뢰하는 루트 CA의 자체 서명 된 X.509 인증서 목록을 포함합니다. 이 MSP 폴더에는 적어도 하나의 루트 CA X.509 인증서가 있어야합니다. 이는 다른 모든 인증서를 파생시켜 해당 조직의 구성원으로 간주해야하는 CA를 식별하기 때문에 가장 중요한 폴더입니다.

• 중간 CA : 이 폴더는이 조직에서 신뢰하는 중간 CA의 X.509 인증서 목록을 포함합니다. 각 인증서는 MSP의 루트 CA 중 하나 또는 서명 된 CA 체인이 궁극적으로 신뢰할 수있는 루트 CA로 연결되는 중간 CA에 의해 서명되어야합니다. 직간접 적으로 해당 조직의 구조와 관련하여 중간 CA를 사용하는 경우 중간 CA는 조직의 다른 하위 또는 조직 자체를 나타낼 수 있습니다 (예 : 상업용 CA가 조직의 ID 관리에 사용되는 경우). 후자의 경우, CA 계층 구조에서 더 낮은 다른 중간 CA를 사용하여 조직 세목을 나타낼 수 있습니다. 여기 에서 MSP 구성에 대한 모범 사례에 대한 자세한 정보를 찾을 수 있습니다. 중개 CA가없는 작동하는 네트워크를 가질 수 있으며이 경우이 폴더는 비어있을 수 있습니다. 루트 CA 폴더와 마찬가지로이 폴더는 조직의 구성원으로 간주되도록 인증서를 발급해야하는 CA를 정의합니다.

• 조직 구성 단위 (OU) : $Fabric_CFG_PATH/msp/config.yaml 디렉토리에 나열되며 조직 구성 단위 목록을 포함합니다. 구성 단위 목록은이 MSP가 대표하는 조직의 구성원으로 간주됩니다. 이는 조직의 구성원을 특정 OU가있는 ID (MSP 지정 CA 중 하나가 서명 한 ID)가있는 조직 구성원으로 제한하려는 경우에 특히 유용합니다. OU를 지정하는 것은 선택 사항입니다. OU가 목록에 없으면 루트 CA 및 중간 CA 폴더로 식별되는 MSP의 일부인 모든 ID가 조직의 구성원으로 간주됩니다.

• 관리자 : 이 폴더는이 조직의 관리자 역할을 맡은 액터를 정의하는 ID 목록을 포함합니다. 표준 MSP 유형의 경우이 목록에 하나 이상의 X.509 인증서가 있어야합니다. 액터가 관리자의 역할을한다고해서 특정 리소스를 관리 할 수있는 것은 아닙니다. 시스템 관리와 ​​관련하여 주어진 신원이 갖는 실제 권한은 시스템 자원을 관리하는 정책에 의해 결정됩니다. 예를 들어, 채널 정책은 ORG1-MANUFACTURING 관리자 에게 채널 에 새 조직을 추가 할 수있는 권한이 있음을 관리자가 지정할 수있는 권한을 지정할 수 있습니다 ORG1-DISTRIBUTION. X.509 인증서에는 ROLE속성 (예 : 액터가 지정되어 있음 admin)이 있지만 이는 블록 체인 네트워크가 아니라 조직 내에서 액터의 역할을 나타냅니다. 이것은 OU속성 의 목적과 유사합니다. 정의 된 경우 속성은 조직의 액터의 위치를 ​​나타냅니다. ROLE속성은 수 채널에 대한 정책 (예 : 인스턴스 chaincode 같은) 특정 채널 기능을 수행하는 조직 (또는 특정 조직) 권한에서 모든 관리자를 할 수 있도록 작성되어있는 경우 채널 수준에서 관리 권한을 부여하는 데 사용. 이러한 방식으로 조직 역할이 네트워크 역할을 부여 할 수 있습니다. 이것은 미국 플로리다 주에서 발행 한 운전 면허증을 소지 한 사람이 미국의 모든 주에서 운전할 수있는 권리를 갖는 것과 개념적으로 유사합니다.

• 해지 된 인증서 : 액터의 신원이 취소 된 경우 ID 자체가 아닌 신원에 관한 정보를 식별하는이 폴더에 보관됩니다. X.509 기반 ID의 경우 이러한 식별자는 SKI (Subject Key Identifier) ​​및 AKI (Authority Access Identifier)로 알려진 문자열 쌍이며 X.509 인증서를 사용하여 인증서가 없는지 확인 될 때마다 확인됩니다 취소됨. 이 목록은 개념적으로 CA의 인증서 해지 목록 (CRL)과 동일하지만 조직의 구성원 자격 해지와 관련이 있습니다. 결과적으로 로컬 또는 채널의 MSP 관리자는 CA의 업데이트 된 CRL을 발급 한 취소 인증서를 광고함으로써 조직에서 배우 또는 노드를 신속하게 취소 할 수 있습니다. 이 "목록 목록"은 선택 사항입니다. 인증서가 폐기되면서 만 채워집니다.

• 노드 신원 : 이 폴더에는 노드의 신원, 즉 KeyStore의 내용과 결합하여 노드가 채널 및 네트워크의 다른 참가자에게 보내는 메시지에서 자신을 인증 할 수있게하는 암호 자료가 들어 있습니다. X.509 기반 ID의 경우이 폴더에는 X.509 인증서 가 포함되어 있습니다 . 이것은 피어가 트랜잭션 제안 응답에 포함시키는 인증서입니다 (예 : 피어가이를 보증했음을 나타 내기 위해). 이후 검증 시간에 결과 트랜잭션의 endorsement policy에 대해 확인할 수 있습니다. 이 폴더는 로컬 MSP에는 필수 항목이며 노드에 정확히 하나의 X.509 인증서가 있어야합니다. 채널 MSP에는 사용되지 않습니다.

• 개인 키용 키 저장소 : 이 폴더는 피어 또는 발주자 노드 (또는 클라이언트의 로컬 MSP)의 로컬 MSP에 대해 정의되며 노드의 서명 키를 포함합니다 . 이 키는 Node Identity 폴더에 포함 된 노드의 ID와 암호 학적으로 일치하며 데이터 서명에 사용됩니다. 예를 들어 승인 단계의 일부로 트랜잭션 제안 응답에 서명하는 데 사용됩니다. 이 폴더는 로컬 MSP에는 필수 항목이며 정확하게 하나의 개인 키가 있어야합니다. 분명히이 폴더에 대한 액세스는 피어에 대한 관리 책임이있는 사용자 인 아이디로만 제한되어야합니다. 채널 MSP의 구성에는 채널 MSP 가 서명 확인 기능이 아닌 신원 확인 기능 만 제공하기 때문에이 부분은 포함되지 않습니다.

• TLS 루트 CA : 이 폴더는 TLS 통신 을 위해이 조직 에서 트러스트 된 루트 CA의 자체 서명 된 X.509 인증서 목록을 포함합니다 . TLS 통신의 예로는 피어가 원장 업데이트를받을 수 있도록 Orderer에게 연결해야 할 때입니다. MSP TLS 정보는 네트워크를 사용하는 노드 (응용 프로그램 및 관리자)가 아닌 네트워크 내부의 노드 (예 : 동료 및 Orderer)와 관련이 있습니다. 이 폴더에는 하나 이상의 TLS 루트 CA X.509 인증서가 있어야합니다.

• TLS 중간 CA : 이 폴더에는 TLS 통신 을 위해이 MSP가 나타내는 조직에서 신뢰하는 중간 CA 인증서 CA 목록이 들어 있습니다 . 이 폴더는 상용 CA가 조직의 TLS 인증서에 사용될 때 특히 유용합니다. 멤버쉽 중간 CA와 마찬가지로 중간 TLS CA를 지정하는 것은 선택 사항입니다. TLS에 대한 자세한 내용은 여기를 클릭 하십시오 .

이 문서와 Identity 에 관한 문서를 읽은 경우 , Hyperledger Fabric에서 ID와 멤버십이 어떻게 작동하는지 꽤 잘 이해해야합니다. PKI와 MSP를 사용하여 블록 체인 네트워크에서 협력하는 액터를 식별하는 방법을 살펴 보았습니다. MSP가 물리적 및 논리적으로 구조화 된 방법 외에도 인증서, 공용 / 개인 키 및 신뢰의 뿌리가 어떻게 작동 하는지를 배웠습니다.

출처 : https://hyperledger-fabric.readthedocs.io/en/release-1.1/membership/membership.html

Bringing up a Kafka-based Ordering Service

Caveat emptor

이 문서는 독자가 일반적으로 Kafka 클러스터와 ZooKeeper 앙상블을 설정하는 방법을 알고 있다고 가정합니다. 이 가이드의 목적은 Hyperledger Fabric ordering 서비스 노드 세트(OSNs)가 Kafka 클러스터를 사용하고 블록 체인 네트워크에 ordering 서비스를 제공하기 위해 취해야 할 단계를 식별하는 것입니다.

Big picture

각 채널은 Kafka의 별도의 단일 파티션 주제에 매핑됩니다. OSN이 Broadcast RPC 를 통해 트랜잭션을 수신 하면 브로드캐스트 클라이언트가 채널에 쓸 수 있는 권한이 있는지 확인한 다음 해당 트랜잭션을 카프카의 적절한 파티션으로 중계합니다. 이 파티션은 수신된 트랜잭션을 로컬 블록으로 그룹화하고 로컬 원장에서 이를 유지하며 Deliver RPC를 통해 클라이언트를 수신하는 OSN에 의해 ​​소비됩니다. 저수준에 대한 자세한 내용은 describes how we came to this design 문서를 참조하십시오. 그림 8은 위에 설명 된 프로세스의 개략적인 표현입니다.

Steps

K와 Z 를 Kafka 클러스터와 ZooKeeper 앙상블의 노드 수로 각각 설정합니다. :

1. K는 최소한 4로 설정해야합니다 (아래 4 단계에서 설명 하겠지만, 이것은 고장 내결함성을 나타내기 위해 필요한 노드의 최소 수입니다. 즉, 4 개의 브로커를 사용하면 1 개의 브로커가 다운 될 수 있습니다. 채널은 계속해서 쓰기 및 읽기가 가능하며 새로운 채널을 만들 수 있습니다.)
2. Z는 3, 5 또는 7 중 하나입니다. 스플릿 브레이브 시나리오를 피하기 위해서는 홀수이어야하며 단일 실패 지점을 피하려면 1보다 커야합니다. 7 개의 ZooKeeper 서버를 초과하는 것은 과잉으로 간주됩니다.

그런 다음 다음과 같이 진행하십시오.

1. Orderer : 네트워크의 기원 블록(genesis block)에 카프카 관련 정보를 암호화하십시오. configtxgen을 사용중인 경우 configtx.yaml을 편집하거나 시스템 채널의 기원 블록(genesis block)에 대한 사전 설정된 프로필을 선택하여 다음과 같이하십시오.
   1. Orderer.OrdererType은 kafka로 설정됩니다.
   2. Orderer.Kafka.Brokers에는 클러스터에 있는 두 개 이상의 Kafka 중개인의 주소가 IP:port으로 들어있습니다. 이 목록은 완전 할 필요는 없습니다. (이들은 부트 스트랩 브로커입니다.)
2. Orderers : 최대 블록 크기를 설정하십시오. 각 블록에는 대부분 Orderer.AbsoluteMaxBytes 바이트(헤더 제외)가 있으며 configtx.yaml에 설정할 수 있습니다. 여기에서 선택한 값을 A로 지정하고 기록해 두십시오 - 6 단계에서 Kafka 중개인을 구성하는 방법에 영향을 줍니다.
3. Orderers : 기원 블록(genesis block)을 만듭니다. configtxgen을 사용합니다. 위의 3 단계와 4 단계에서 선택한 설정은 시스템 전체의 설정입니다. 즉, 모든 OSN에 대해 네트워크 전체에 적용됩니다. 기원 블록(genesis block)의 위치를 ​​기록하십시오.
4. Kafka 클러스터 : Kafka brokers를 적절하게 구성하십시오. 모든 카프카 중개인은 다음과 같은 키를 구성해야합니다.
   1. unclean.leader.election.enable = false - 데이터 일관성은 블록 체인 환경에서 핵심입니다. 동기화된 복제 세트 외부에서 채널 리더를 선택할 수 없거나 이전 리더가 생성한 오프셋을 덮어 쓸 위험이 있습니다. 결과적으로 orderer가 생산하는 블록 체인을 다시 작성합니다.
   2. min.insync.replicas = M -  1 < M < N와 같은 M 값을 선택하십시오(아래 default.replication.factor 참조). 데이터는 최소한 M개의 복제본에 기록 될 때 커밋된 것으로 간주됩니다 (동기화 후 동기화 된 것으로 간주되고 동기화 된 복제 집합 또는 ISR에 속함). 다른 경우, 쓰기 조작은 오류를 리턴합니다. 그때:
      1. 채널 데이터가 기록되는 N개까지의 N-M 복제본을 사용할 수 없게 되면 작업이 정상적으로 진행됩니다.
      2. 더 많은 복제본을 사용할 수 없게 되면 Kafka는 M의 ISR 집합을 유지할 수 없으므로 쓰기 허용을 중지합니다. 문제없이 작업을 읽습니다. 채널은 M개의 복제본이 동기화 될 때 채널에 다시 쓸 수 있게 됩니다.
   3. default.replication.factor = N - 여기서 N < K인 값 N을 선택합니다. N의 복제 인수는 각 채널이 N개의 브로커에 복제된 데이터를 갖게됨을 의미합니다. 이들은 채널의 ISR 세트 후보입니다. 위의 min.insync.replicas section에서 언급했듯이 모든 브로커가 항상 사용 가능해야하는 것은 아닙니다.  N 브로커보다 적으면 채널 생성을 진행할 수 없으므로 N을 K보다 반드시 작게 설정해야합니다. 따라서 N = K로 설정하는 경우 단일 브로커가 중단된다는 것은 블록 체인 네트워크에 새로운 채널을 만들 수 없다는 것을 의미합니다. ordering 서비스의 오류 방지 기능은 존재하지 않습니다. 위에서 설명한 것을 바탕으로, M과 N의 최소 허용 값은 각각 2, 3입니다. 이 구성은 앞으로 나아갈 새로운 채널을 생성하고 모든 채널이 계속 쓰기 가능하도록 합니다.
   4. message.max.bytes 및 replica.fetch.max.bytes는 위의 4단계의 Orderer.AbsoluteMaxBytes에서 선택한 A 값보다 큰 값으로 설정되어야합니다. 헤더를 설명할 버퍼를 추가하십시오. 1 MiB가 충분합니다. 다음 조건이 적용됩니다. : Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes  (완전성을 위해 message.max.bytes는 기본적으로 100 MiB로 설정되는 socket.request.max.bytes 값보다 작아야 하며, 100 MiB보다 큰 블록을 사용하려면 fabric/orderer/kafka/config.go에 있는 brokerConfig.Producer.MaxMessageBytes의 하드 코딩된 값을 수정하고 소스에서 이진 파일을 다시 작성해야 합니다. 이것은 권장되지 않습니다.)
   5. log.retention.ms = -1. ordering 서비스가 Kafka 로그의 가지 치기에 대한 지원을 추가 할 때까지는 시간 기반 보존을 비활성화하고 세그먼트가 만료되지 않도록해야합니다. (크기 기반 보존 - log.retention.bytes -는 본문 작성 시점에 Kafka에서는 기본적으로 비활성화되어 있으므로 명시적으로 설정할 필요가 없습니다.)
5. Orderers : 각 OSN을 기원 블록(genesis block)으로 향하게 하십시오. General.GenesisFile을 orderer.yaml에서 편집하여 위의 5 단계에서 생성된 기원 블록(genesis block)을 가리키도록 합니다. (그 동안 YAML 파일의 다른 모든 키가 적절하게 설정되었는지 확인하십시오.)
6. Orderers : 폴링 간격 및 타임 아웃을 조정합니다. (선택 단계.)
   1. orderer.yaml 파일의 Kafka.Retry 섹션을 사용하여 메타 데이터/제작자/고객 요청의 빈도와 소켓 시간 초과를 조정할 수 있습니다. (이들은 Kafka 제작자 또는 소비자에게 기대되는 모든 설정입니다.)
   2. 또한 새 채널이 생성되거나 기존 채널이 다시 로드 될 때 (orderer가 방금 다시 시작된 경우) orderer는 다음과 같은 방법으로 Kafka 클러스터와 상호 작용합니다.
      1. 채널에 해당하는 Kafka 파티션을위한 Kafka 제작자 (작성자)를 만듭니다.
      2. 해당 생성자를 사용하여 해당 파티션에 no-op CONNECT 메시지를 게시 합니다.
      3. 해당 파티션에 대한 Kafka 소비자 (판독기)를 만듭니다. 이러한 단계 중 하나라도 실패하면 반복되는 빈도를 조정할 수 있습니다. 구체적으로 그들은 Kafka.Retry.ShortInterval의 총합을 위해 Kafka.Retry.ShortInterval마다 다시 시도될 것이며, Kafka.Retry.LongInterval을 성공할 때까지 Kafka.Retry.LongTotal의 총합을 구하기 재시도합니다. 위의 모든 단계가 성공적으로 완료 될 때까지 orderer는 채널에 쓰거나 채널에서 읽을 수 없습니다.
7. SSL을 통해 통신할 수 있도록 OSN 및 Kafka 클러스터를 설정합니다. (옵션 단계이지만 적극 추천합니다.) 방정식의 Kafka 클러스터 측면에 대해서는 Confluent 가이드 문서를 참조하고 그에 따라 모든 OSN에서 Kafka.TLS의 키를 orderer.yaml로 설정하십시오.
8. ZooKeeper 앙상블, Kafka 클러스터, ordering 서비스 노드 순서로 노드를 가져옵니다.

Additional considerations

1. 기본 메시지 크기. 위의 4 단계 (Steps 섹션 참조)에서 Orderer.Batchsize.PreferredMaxBytes 키를 설정하여 원하는 블록 크기를 설정할 수도 있습니다. 상대적으로 작은 메시지를 처리 ​​할 때 Kafka는 높은 처리량을 제공합니다. 1 MiB보다 크지 않은 값을 목표로 삼는다.
2. 환경 변수를 사용하여 설정을 무시합니다. Fabric과 함께 제공되는 샘플 Kafka 및 Zookeeper Docker 이미지 (images/kafka 및 images/zookeeper 참조)를 사용하는 경우, 환경 변수를 사용하여 Kafka 브로커 또는 ZooKeeper 서버의 설정을 무시할 수 있습니다. 구성 키의 점을 밑줄로 바꾸십시오 - 예를 들어 KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false를 지정하면 unclean.leader.election.enable의 기본값을 무시할 수 있습니다. 로컬 구성에 대한 OSN에도 동일하게 적용됩니다 ( 즉, orderer.yaml에서 설정할 수 있는 항목). 예를 들어 ORDERER_KAFKA_RETRY_SHORTINTERVAL=1s이면 Orderer.Kafka.Retry.ShortInterval의 기본값을 재정의할 수 있습니다.

Kafka Protocol Version Compatibility

패브릭은 sarama 클라이언트 라이브러리와 공급 업체를 사용하여 Kafka 0.10에서 1.0까지 지원하지만 아직 이전 버전에서 작동하는 것으로 알려져 있습니다.

orderer.yaml의 Kafka.Version 키를 사용하여 Kafka 클러스터의 브로커와 통신하는 데 사용되는 Kafka 프로토콜 버전을 구성할 수 있습니다. Kafka 브로커는 이전 버전의 프로토콜과 역 호환됩니다. Kafka 브로커의 이전 프로토콜 버전과의 이전 호환성으로 인해 Kafka 브로커를 새 버전으로 업그레이드하는 경우 Kafka.Version 키 값을 업데이트할 필요는 없지만 Kafka 클러스터는 이전 프로토콜 버전을 사용하는 동안 성능이 저하 될 수 있습니다.

Debugging

General.LogLevel을 DEBUG로 설정하고 orderer.yaml의 Kafka.Verbose를 true로 설정합니다.

Example

Sample Docker 위의 권장 설정으로 인라인 구성 파일을 작성하려면 fabric/bddtests 디렉토리 아래에 있습니다. dc-orderer-kafka-base.yml 및 dc-orderer-kafka.yml를 찾으십시오.

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/kafka.html

Securing Communication With Transport Layer Security (TLS)

패브릭은 TLS를 사용하는 노드 간의 보안 통신을 지원합니다. TLS 통신은 단방향 (서버 만) 및 양방향 (서버 및 클라이언트) 인증을 모두 사용할 수 있습니다.

Configuring TLS for peers nodes

피어 노드는 TLS 서버와 TLS 클라이언트입니다. 다른 피어 노드, 응용 프로그램 또는 CLI가 다른 피어 노드 또는 Orderer와 연결될 때 다른 피어 노드, 응용 프로그램 또는 CLI가 이 노드에 연결하고 후자를 피어 노드로 연결하면 전자가 됩니다.

피어 노드에서 TLS를 사용하도록 설정하려면 다음 피어 구성 속성을 설정하십시오.

• peer.tls.enabled = true
• peer.tls.cert.file = TLS 서버 인증서가 포함 된 파일의 정규화 된 경로
• peer.tls.key.file = TLS 서버 개인 키가 들어있는 파일의 정규화 된 경로
• peer.tls.rootcert.file = TLS 서버 인증서를 발급한 인증 기관(CA)의 인증서 체인을 포함하는 파일의 정규화 된 경로

기본적으로 TLS 클라이언트 인증은 피어 노드에서 TLS를 사용하도록 설정하면 해제됩니다. 즉, 피어 노드는 TLS 핸드 셰이크 중에 클라이언트 (다른 ​​피어 노드, 응용 프로그램 또는 CLI)의 인증서를 확인하지 않습니다. 피어 노드에서 TLS 클라이언트 인증을 사용하려면 피어 구성 속성 peer.tls.clientAuthRequired를 true로 설정하고 peer.tls.clientRootCAs.files 속성을 조직의 클라이언트에 대해 TLS 인증서를 발급한 CA 인증서 체인이 포함 된 CA 체인 파일로 설정합니다.

기본적으로 피어 노드는 TLS 서버 및 클라이언트로 작동 할 때 동일한 인증서 및 개인 키 쌍을 사용합니다. 클라이언트 측에 대해 다른 인증서와 개인 키 쌍을 사용하려면 peer.tls.clientCert.file 및 peer.tls.clientKey.file 구성 등록 정보를 각각 클라이언트 인증서와 키 파일의 정규화된 경로로 설정하십시오.

클라이언트 인증을 사용하는 TLS는 다음 환경 변수를 설정하여 활성화 할 수도 있습니다.

• CORE_PEER_TLS_ENABLED = true
• CORE_PEER_TLS_CERT_FILE = 서버 인증서의 정규화 된 경로
• CORE_PEER_TLS_KEY_FILE = 서버 개인 키의 정규화 된 경로
• CORE_PEER_TLS_ROOTCERT_FILE = CA 체인 파일의 정규화 된 경로
• CORE_PEER_TLS_CLIENTAUTHREQUIRED = true
• CORE_PEER_TLS_CLIENTROOTCAS_FILES = CA 체인 파일의 정규화 된 경로
• CORE_PEER_TLS_CLIENTCERT_FILE = 클라이언트 인증서의 정규화 된 경로
• CORE_PEER_TLS_CLIENTKEY_FILE = 클라이언트 키의 정규화 된 경로

클라이언트 인증이 피어 노드에서 활성화되면 클라이언트는 TLS 핸드 셰이크 중에 인증서를 보내야합니다. 클라이언트가 인증서를 보내지 않으면 핸드 셰이크가 실패하고 피어는 연결을 닫습니다.

피어가 채널에 조인하면 채널 구성원의 루트 CA 인증서 체인이 채널의 config 블록에서 읽히고 TLS 클라이언트 및 서버 루트 CA 데이터 구조에 추가됩니다. 따라서 피어 투 피어 통신, 피어 투 발주자 통신은 매끄럽게 작동해야합니다.

Configuring TLS for orderer nodes

orderer 노드에서 TLS를 사용하려면 다음 orderer 구성 등록 정보를 설정하십시오.

• General.TLS.Enabled = true
• General.TLS.PrivateKey = 서버 개인용 키가 들어있는 파일의 완전한 경로
• General.TLS.Certificate = 서버 인증서를 포함하는 파일의 정규화 된 경로
• General.TLS.RootCAs = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

기본적으로 TLS 클라이언트 인증은 피어의 경우와 마찬가지로 orderer에서 해제됩니다. TLS 클라이언트 인증을 사용하려면 다음 구성 등록 정보를 설정하십시오.

• General.TLS.ClientAuthRequired = true
• General.TLS.ClientRootCAs = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

클라이언트 인증을 사용하는 TLS는 다음 환경 변수를 설정하여 활성화 할 수도 있습니다.

• ORDERER_GENERAL_TLS_ENABLED = true
• ORDERER_GENERAL_TLS_PRIVATEKEY = 서버 개인용 키가 들어있는 파일의 완전한 경로
• ORDERER_GENERAL_TLS_CERTIFICATE = 서버 인증서를 포함하는 파일의 정규화 된 경로
• ORDERER_GENERAL_TLS_ROOTCAS = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로
• ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED = true
• ORDERER_GENERAL_TLS_CLIENTROOTCAS = TLS 서버 인증서를 발급 한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

Configuring TLS for the peer CLI

TLS 사용 가능 피어 노드에 대해 피어 CLI 명령을 실행하는 경우 다음 환경 변수를 설정해야합니다.

• CORE_PEER_TLS_ENABLED = true
• CORE_PEER_TLS_ROOTCERT_FILE = TLS 서버 인증서를 발급한 CA의 인증서 체인을 포함하는 파일의 정규화 된 경로

원격 서버에서 TLS 클라이언트 인증을 사용하는 경우 위의 변수 외에 다음 변수를 설정해야합니다.

• CORE_PEER_TLS_CLIENTAUTHREQUIRED = true
• CORE_PEER_TLS_CLIENTCERT_FILE = 클라이언트 인증서의 정규화 된 경로
• CORE_PEER_TLS_CLIENTKEY_FILE = 클라이언트 개인 키의 완전한 경로

피어 채널 <create | update | fetch> 또는 피어 체인 코드 <invoke | instantiate> 와 같이 orderer 서비스에 연결하는 명령을 실행하는 경우 Orderer에서 TLS를 사용하는 경우 다음 명령 줄 인수도 지정해야합니다.

• -tls
• -cafile <orderer의 인증 코드 체인을 포함하는 파일의 완전한 경로 CA>

TLS 클라이언트 인증이 orderer에 대해 사용 가능한 경우 다음 인수도 지정해야합니다.

• -clientauth

• -keyfile <클라이언트 개인 키가 들어있는 파일의 완전한 경로>
• -certfile <클라이언트 인증서가 들어있는 파일의 전체 경로>

Debugging TLS issues

TLS 문제를 디버깅하기 전에 TLS 클라이언트와 서버 측 모두에서 GRPC debug를 활성화 하여 추가 정보를 얻는 것이 좋습니다. GRPC debug를 사용하려면 CORE_LOGGING_GRPC 환경 변수를 DEBUG로 설정하십시오.

클라이언트 쪽에서 remote error: tls: bad certificate 오류 메시지가 표시 되면 일반적으로 TLS 서버에서 클라이언트 인증을 사용하고 서버가 올바른 클라이언트 인증서를 받지 못했거나 신뢰할 수없는 클라이언트 인증서를 받았다는 의미입니다. 클라이언트가 인증서를 보내고 피어 또는 orderer 노드가 신뢰하는 CA 인증서 중 하나가 서명했는지 확인하십시오.

체인 코드 로그에 remote error: tls: bad certificate 오류 메시지가 표시되면 Fabric v1.1 이상에서 제공되는 체인 코드 심을 사용하여 체인 코드가 빌드되었는지 확인하십시오. chaincode에 shim의 판매자 된 사본이 없으면 chaincode 컨테이너를 삭제하고 해당 피어를 다시 시작하면 현재 shim 버전을 사용하여 chaincode 컨테이너를 다시 작성합니다. 체인 코드가 이전 버전의 shim을 제공했다면, vend -vendored-shim 을 업그레이드 하는 방법에 대한 문서를 검토하십시오.

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/enable_tls.html