Настройка сети Hyperledger Fabric с несколькими кластерами: полное руководство

Технология блокчейн стала настоящим прорывом во многих отраслях, предоставляя децентрализованные и неизменяемые возможности ведения учета, которые решают давние проблемы в области целостности данных и доверия.

Среди множества доступных фреймворков блокчейна Hyperledger Fabric стал одним из лучших разрешенных блокчейнов, который особенно ценят за его модульность, гибкость и готовность к использованию в бизнесе.

Это подробное руководство рассказывает о сложном процессе создания мультикластерной конфигурации Hyperledger Fabric, а также о построении мультикластерной сети Hyperledger Fabric с участием нескольких организаций.

Распределяя сетевые компоненты между разными кластерами и организациями, можно добиться лучшей отказоустойчивости, возможностей масштабирования и автономности организаций.

Каждый шаг был тщательно описан, чтобы дать как техническую глубину, так и практические идеи для реализации.

Прежде чем начинать внедрение, важно понять архитектурные основы, описанные в этом руководстве по архитектуре Hyperledger Fabric.

Мультикластерная архитектура — это сложная конструкция для развертывания блокчейн-сети, которая сочетает в себе совместную работу и организационную независимость.

В этой архитектурной модели мы имеем дело с двумя разными организациями, у каждой из которых есть свой центр сертификации, который отвечает за управление криптографическими идентификаторами и обеспечение безопасной аутентификации.

Эти организации работают независимо, их ресурсы работают в разных кластерах Kubernetes Hyperledger Fabric.

Такое разделение дает важные преимущества, такие как отказоустойчивость, изоляция ресурсов и возможность каждой организации сохранять контроль над своей инфраструктурой.

Кластер настроен так, что каждая организация держит свою группу и сертификационный центр в отдельной среде.

Такой подход к дизайну гарантирует, что не будет конфликтов за ресурсы, и позволяет организациям масштабировать свою инфраструктуру в соответствии со своими конкретными потребностями, не влияя на других участников сети.

Сервис заказа, который действует как механизм консенсуса для сети, стратегически распределен по разным организациям.

Разместив два ордера в разных кластерах, архитектура получает избыточность и высокую доступность.

Если у одного заказчика возникают проблемы, сеть продолжает работать через другого заказчика, чтобы никогда не останавливаться.

В реализации используются тщательно подобранные инструменты, которые упрощают развертывание сложных систем и добавляют надежные возможности управления.

EKS упрощает развертывание, управление и масштабирование кластеров Kubernetes на инфраструктуре Amazon Web Services, предоставляя надежную и проверенную платформу для хостинга сетевых компонентов Fabric.

Управляемый характер EKS означает, что он снижает накладные расходы, связанные с работой системы, и при этом обеспечивает надежность корпоративного уровня.

Hlf-Operator — это специальный оператор Kubernetes, который был разработан специально для управления развертыванием сети Hyperledger Fabric и текущими операциями для сетей Hyperledger Fabric.

Этот оператор упрощает многие сложные задачи развертывания и управления, связанные с сетями Fabric, и предлагает набор декларативных параметров конфигурации, которые значительно облегчают администрирование сети и снижают вероятность ошибок в настройках.

После того, как вы поняли архитектуру и определили инструменты, процесс внедрения идет по четкой последовательности шагов, которые строятся друг на друге, чтобы создать полноценную сеть.

Шаг 1: Настройка кластера EKS

Первый этап внедрения включает создание кластеров Kubernetes, где будут находиться компоненты сети Fabric.

Этот важный шаг требует тщательного планирования, чтобы убедиться, что кластеры настроены правильно для блокчейн-задач.

Настройка кластера начинается с определения параметров, которые будут влиять на его работу и мощность.

Эти параметры включают:

• •Типы экземпляров, которые выбираются исходя из ожидаемых характеристик рабочей нагрузки
• •Сколько экземпляров нужно, чтобы справиться с ожидаемым объемом транзакций
• •Зоны доступности, которые выбраны, чтобы быть максимально устойчивыми и с минимальной задержкой

С помощью eksctl, специального инструмента командной строки, который был разработан для управления кластерами EKS, кластеры создаются в соответствии с определенными спецификациями.

Этот инструмент упрощает много сложных вещей, связанных с настройкой кластеров, и при этом следит за тем, чтобы всё было сделано правильно.

После создания кластеров генерируются файлы kubeconfig, чтобы обеспечить безопасный доступ к новым кластерам.

Эти файлы настройки содержат все данные для аутентификации и подключения, которые понадобятся для следующих шагов развертывания.

Шаг 2: Установите Hlf-Operator и Istio

Когда кластеры запущены, следующий шаг — установить инструменты управления, которые помогут развернуть компоненты Fabric и обеспечить связь между сервисами.

Установка Hlf-Operator начинается с добавления репозитория Helm, где есть диаграммы оператора.

Как только репозиторий будет готов, оператор устанавливается на оба кластера, предоставляя определения пользовательских ресурсов и контроллеры, нужные для управления компонентами Fabric.

Далее идет установка Istio, которая добавляет возможности сервисной сетки в кластеры.

Istio позволяет делать некоторые продвинутые вещи по управлению трафиком, балансировке нагрузки и наблюдаемости, что очень полезно в распределенных сетях блокчейна, где важно, чтобы между компонентами была надежная связь.

Настройка системы доменных имен определяет структуру именования, которая позволяет легко обмениваться данными между сетевыми компонентами, которые находятся в разных кластерах.

Чтобы настроить DNS, нужно создать зону хостинга в AWS Route 53 для домена, который будет связан с сетью Fabric.

В этой зоне для каждого компонента службы есть отдельные записи, которые связывают понятные для людей доменные имена с конечной точкой кластера.

Для каждого из пиров, центра сертификации и заказчика устанавливается запись CNAME, указывающая на соответствующий внешний URL кластера.

Эта настройка позволяет компонентам в кластере находить и общаться с компонентами в других кластерах, используя понятные и предсказуемые доменные имена.

Структура записей DNS:

• •Для первой организации записи создаются для центра сертификации и одноранговых узлов
• •Вторая организация должна иметь свой собственный набор записей
• •Организация-заказчик требует записи для своего центра сертификации и нескольких заказчиков, которые указывают на соответствующие конечные точки кластера.

Когда инфраструктура и сеть готовы, начинаем устанавливать компоненты Fabric, сначала сертификационные центры и узлы для каждой организации.

Центральные органы сертификации — это те, кому доверяют в своих организациях, и они выдают криптографические идентификаторы, которые участники используют для аутентификации и авторизации действий в сети.

Каждая организация настраивает свой центр сертификации (CA) по своим правилам, включая данные для регистрации, настройки TLS и другие параметры безопасности.

Peers — это узлы обработки транзакций внутри каждой организации.

Эти компоненты хранят копии реестра, запускают цепочку кода и подтверждают транзакции на основе политики подтверждения сети.

Развертывание на одноранговом узле — для развертывания CA указываются требования к хранению, распределение ресурсов и настройки подключения.

Для первой организации:

• •Сначала запускается CA, а потом узлы-аналоги
• •Конфигурационные файлы указывают конкретные параметры для каждого компонента, такие как идентификаторы bootstrap, классы хранения и типы сервисов
• •После того, как эти настройки применены, компоненты проверяются, пока не будут готовы

Вторая организация имеет похожую схему развертывания, при этом ее CA и ее одноранговые узлы настроены в соответствии с требованиями конкретной организации.

Хотя в целом процесс похож на то, что делали в первой организации, некоторые настройки отличаются, чтобы показать разные конфигурации кластера и домена.

Организация-заказчик играет особую роль в сети, так как она обеспечивает механизм консенсуса, который используется для упорядочения транзакций и создания блоков, которые будут распределены между участниками.

Создание Orderer CA — это создание центра сертификации, который будет отвечать за выдачу идентификаторов узлам Orderer.

Этот CA не связан с CA организации и делает разграничение между заказом услуг и подтверждением транзакций более четким.

Первый заказчик развертывается с конфигурацией, где указано:

• •Его связь с заказчиком CA
• •Требования к хранению
• •Настройки блока Genesis

Этот заказчик — первый анкор для службы заказов.

Развертывание второго ордера добавляет дополнительный уровень сложности из-за того, что этот ордер находится в отдельном кластере.

Сделаны такие изменения:

• •Ссылки на хост CA должны указывать на домен CA заказчика
• •Хост CA добавляется в запрос на подпись сертификата
• •Сертификаты CA TLS копируются из конфигурации первого заказчика

Эти настройки нужны, чтобы второй заказчик мог правильно аутентифицироваться и общаться с центром сертификации службы заказов.

После настройки конфигурации второй заказчик развертывается и контролируется до тех пор, пока не начнет работать.

На данном этапе сеть имеет полный набор основных компонентов инфраструктуры, все центры сертификации, пиры и ордереры работают и доступны.

Каналы в Hyperledger Fabric обеспечивают частные каналы связи между конкретными участниками сети, позволяя осуществлять конфиденциальные транзакции и выборочный обмен данными.

Создание канала начинается с регистрации и ввода административных идентификаторов для каждой организации и организации-заказчика.

Эти идентификаторы имеют права, нужные для управления каналами.

Чтобы зарегистрироваться, нужно:

• •Связь с соответствующим CA
• •Создавайте учетные записи пользователей с атрибутами администратора

После регистрации при вступлении создаются криптографические материалы для каждой идентичности (подписывающие сертификаты и закрытые ключи).

Когда все административные идентификаторы будут готовы, их соберут в секрет Kubernetes, на который будут ссылаться во время работы канала.

Этот секрет содержит криптографические материалы, нужные для управления каналом.

Основной канал настраивается с помощью спецификаций, которые определяют:

• •Участвующие организации
• •Заказчики отвечают за канал
• •Правила, которые регулируют работу и изменения каналов

Этот процесс инициализации создает блок генезиса для канала и настраивает его конфигурацию.

Коллеги из обеих организаций присоединяются к каналу, ссылаясь на настройки основного канала и предоставляя свои учетные данные организации.

Этот процесс присоединения делает канал видимым для других участников и позволяет им получать блоки, в которых есть транзакции канала.

Для каждой организации создаются каналы подписчиков, чтобы установить связь между коллегами и каналом.

Эти настройки показывают, какой узел должен следить за каким каналом, и помогают настроить цепочку членства.

Chaincode, реализация смарт-контракта в Hyperledger Fabric, — это бизнес-логика, которая описывает обработку транзакций и управление состоянием в блокчейне.

Жизненный цикл цепочки кода начинается с упаковки цепочки кода в виде готового к развертыванию артефакта.

В этой реализации chaincode развернут как сервис, который требует:

• •Создание образа Docker с кодом цепочки
• •Подготовка метаданных подключения, которые показывают, как пиры должны подключаться к службе chaincode

Для первой организации:

• •Упакованный цепочный код устанавливается на пир, делая пакет цепочного кода доступным для развертывания
• •Готовим файл настроек подключения, в который вписываем адрес и данные TLS для подключения к сервису chaincode
• •Затем цепочка кода развертывается как сервис Kubernetes в кластере организации, делая его доступным для коллег по организации.

После того, как определение цепочки кода развернуто, организация утверждает его, показывая, что готова использовать эту версию цепочки кода в канале.

После того, как все организации одобрят определение цепочки кода, оно фиксируется в канале, что делает его активным и готовым к вызову.

Этот процесс создания обязательства создает контейнер chaincode и делает его авторитетной реализацией для канала.

Вторая организация проходит похожий процесс установки и устанавливает тот же пакет chaincode на своих узлах, а также развертывает службу chaincode в своем кластере.

После установки и развертывания цепочка кода готова к использованию по всей сети.

Когда все компоненты установлены и настроены, проверка гарантирует, что сеть работает как надо и может правильно обрабатывать транзакции.

Тестирование транзакций включает в себя запуск тестовых транзакций, которые проверяют логику цепочки кода.

Эти операции:

• •Отправляйте коллегам, которые имитируют выполнение транзакции и возвращают подтверждения транзакции
• •Отправляйте в сервис упорядочивания, который группирует их в блоки и отправляет всем участникам канала

Чтобы всё прошло гладко, убедитесь, что:

• •Общение между пользователями работает как надо
• •Правила о рекламе соблюдаются
• •Сервис заказов правильно упорядочивает транзакции
• •Изменения в состоянии правильно отображаются у всех участников

Создание сети Hyperledger Fabric с несколькими кластерами и организациями требует тщательного планирования, аккуратной настройки и координации многих компонентов и инструментов.

Процесс включает в себя:

• •Создавайте изолированную, но связанную инфраструктуру
• •Внедрение специальных элементов блокчейна
• •Настройка безопасных каналов связи
• •Проверяйте, что всё работает как надо, тестируя транзакции

От такого подхода к архитектуре можно получить следующие преимущества:

• •Улучшили отказоустойчивость, распределив компоненты по сети
• •Улучшили масштабируемость, разделив ресурсы организации
• •Улучшили контроль над инфраструктурой и операциями
• •Больше гибкости, чтобы подстраивать сеть под новые требования

Полученная инфраструктура блокчейна — это надежная основа, которую можно использовать для разных целей в разных отраслях, от отслеживания цепочки поставок до финансовых расчетов и управления медицинскими записями.

Разрешенный характер Hyperledger Fabric в сочетании с мультикластерной архитектурой обеспечивает платформу, которая балансирует прозрачность и неизменность блокчейна с требованиями конфиденциальности и контроля корпоративных приложений.

Есть несколько улучшений, которые можно внести, чтобы сделать процесс развертывания еще лучше и расширить возможности сетевой архитектуры.

Автоматизация — это отличная возможность для улучшения.

Разработка скриптов и шаблонов инфраструктуры как кода может быть полезна для:

• •Упростите процесс настройки
• •Старайтесь как можно меньше настраивать вручную
• •Старайтесь не делать ошибок

Такая автоматизация позволит развертывать сеть более повторяемым образом и сделает ее доступной для организаций с разным уровнем знакомства с блокчейном.

Если будем больше поддерживать развертывание в нескольких облаках, сеть станет более устойчивой и гибкой.

Размещение разных организаций у разных облачных провайдеров, например, одна организация на AWS, другая на Google Cloud Platform, а третья на Microsoft Azure, гарантирует, что не будет зависимостей между отдельными облаками, но организации смогут использовать свои любимые облачные среды, при этом участвуя в единой сети блокчейна.

Эти улучшения будут основываться на прочной основе, созданной текущей реализацией, расширяя возможности сети и делая ее еще более подходящей для развертывания в производственных предприятиях.