Налаштування багатокластерної мережі 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 та інші параметри безпеки.

Однорангові вузли — це вузли обробки транзакцій у кожній організації.

Ці компоненти зберігають копії реєстру, виконують ланцюговий код і затверджують транзакції на основі політики затвердження мережі.

Розгортання однорангових вузлів — для розгортання CA визначаються вимоги до сховища, розподіл ресурсів та налаштування підключення.

Для першої організації:

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

Друга організація має подібну схему розгортання, причому її CA та її однорангові вузли налаштовані відповідно до вимог, специфічних для організації.

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

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

Створення CA замовника створює центр сертифікації, який буде відповідати за видачу ідентифікаторів вузлам замовника.

Цей CA не пов'язаний з CA організації та посилює розділення між замовленням послуг та підтвердженням транзакцій.

Перший замовник розгортається з конфігурацією, що визначає:

• •Його зв'язок із замовником CA
• •Вимоги до зберігання
• •Налаштування блоку Genesis

Цей замовник є першим анкором для служби замовлення.

Розгортання другого сортувальника додає додатковий рівень складності через розташування цього сортувальника в окремому кластері.

Вносяться такі конкретні зміни:

• •Посилання на хост CA повинні вказувати на домен CA замовника
• •CA-хост додається до запиту на підписання сертифіката
• •Сертифікати CA TLS копіюються з конфігурації першого замовника

Ці коригування виконуються для того, щоб другий замовник міг правильно аутентифікуватися та спілкуватися з CA служби замовлення.

Після налаштування конфігурації другий замовник розгортається і контролюється до моменту введення в експлуатацію.

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

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

Створення каналу починається з реєстрації та зарахування адміністративних ідентифікаторів для кожної організації та організації-замовника.

Ці ідентичності мають привілеї, необхідні для виконання операцій з управління каналами.

Процес реєстрації вимагає:

• •Підключення до відповідного CA
• •Створення облікових записів користувачів з атрибутами адміністратора

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

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

Цей секрет об'єднує криптографічні матеріали, необхідні для управління каналом.

Основний канал ініціалізується за допомогою специфікацій, які визначають:

• •Організації-учасниці
• •Замовники відповідають за канал
• •Політики, що регулюють роботу та модифікації каналу

Цей процес ініціалізації створює блок генезису для каналу та створює конфігурацію для каналу.

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

Цей процес приєднання робить канал видимим для однорангових вузлів і дозволяє їм отримувати блоки, що містять транзакції каналу.

Для кожної організації створюються канали для підписників, щоб встановити зв'язок між колегами та каналом.

Ці конфігурації містять інформацію про те, який одноранговий вузол повинен слідувати за яким каналом, і завершують налаштування членства в ланцюжку.

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

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

У цій реалізації ланцюговий код розгортається як послуга, яка вимагає:

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

Для першої організації:

• •Упакований ланцюговий код встановлюється на одноранговому комп'ютері, що робить пакет ланцюгового коду доступним для розгортання
• •Готується файл конфігурації з'єднання, що містить адресу та деталі з'єднання TLS для служби chaincode.
• •Потім ланцюговий код розгортається як служба Kubernetes у кластері організації, що робить його доступним для колег організації.

Після розгортання визначення ланцюгового коду організація затверджує визначення ланцюгового коду, вказуючи, що вона готова використовувати цю версію ланцюгового коду в каналі.

Після того, як всі організації затвердять визначення ланцюгового коду, він буде зафіксований у каналі, що зробить його активним і готовим до виклику.

Цей процес зобов'язання створює контейнер ланцюгового коду і робить його авторитетним впровадженням для каналу.

Друга організація проходить подібний процес інсталяції та інсталює той самий пакет chaincode на своїх однорангових вузлах і розгортає службу chaincode у своєму кластері.

Після встановлення та розгортання ланцюговий код готовий до використання в мережі.

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

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

Ці операції є такими:

• •Надіслано колегам, які імітують виконання транзакції та повертають підтвердження транзакції
• •Надіслано до служби замовлення, яка упорядковує їх у блоки та надсилає всім учасникам каналу

Успішна обробка транзакцій гарантує, що:

• •Комунікація між рівними користувачами працює належним чином
• •Політика щодо схвалення дотримується належним чином
• •Служба замовлення упорядковує транзакції у відповідному порядку
• •Зміни стану відображаються правильно у всіх однорангових вузлах

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

Процес включає:

• •Створення ізольованої, але пов'язаної інфраструктури
• •Впровадження спеціалізованих елементів блокчейну
• •Налаштування безпечних каналів зв'язку
• •Перевірка правильності роботи шляхом тестування транзакцій

Такий підхід до архітектури дає наступні переваги:

• •Покращена відмовостійкість завдяки розподілу компонентів по мережі
• •Покращена масштабованість завдяки розділенню організаційних ресурсів
• •Посилення організаційного контролю над інфраструктурою та операціями
• •Підвищена гнучкість для адаптації мережі до мінливих вимог

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

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

Існує кілька вдосконалень, які можна внести для подальшого поліпшення процесу розгортання та розширення можливостей архітектури мережі.

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

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

• •Спростіть процес налаштування
• •Мінімізуйте кількість кроків ручної конфігурації
• •Мінімізуйте ймовірність людської помилки

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

Збільшення підтримки багатохмарних розгортань зробить мережу більш стійкою та гнучкою.

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

Ці вдосконалення будуть базуватися на міцній основі, сформованій поточним впровадженням, розширюючи можливості мережі та роблячи її ще більш придатною для впровадження у виробничих підприємствах.