Настройка базы данных состояний Hyperledger Fabric в качестве кластера CouchDB с использованием контейнеризации

Обзор

В DLT Labs мы используем несколько технологий распределенного реестра, но, вероятно, наибольшее внимание уделяется Hyperledger Fabric.

Мы создаем продукты корпоративного класса. За два года разработки на этой платформе я столкнулся с некоторыми уникальными проблемами, связанными с масштабом и дополнительными требованиями к крупномасштабным системам.

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

Продукт уже использовал Apache CouchDB в качестве своего состояния. база данных в Fabric, чтобы множество других компонентов могли напрямую запрашивать регистр и получать более широкие возможности запросов. Нам нужна была высокая доступность базы данных для этих других компонентов и чтобы создаваемая ими нагрузка не влияла на доступность однорангового узла. Мы предполагали, что добавление дополнительных узлов CouchDB при посредничестве балансировщика нагрузки может сделать это.

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

Давайте посмотрим, как мы настроили этот кластер CouchDB и начнем использовать его в сети Hyperledger Fabric.

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

Поскольку в Hyperledger Fabric мы запускаем узлы как контейнеры, мы будем настраивать кластер CouchDB с использованием контейнеризации.

Этот процесс состоит из 5 основных частей:

1. Организация необходимых файлов конфигурации
2. Настройка кластера Couch DB
3. Проверка настройки кластера CouchDB
4. Важные параметры конфигурации
5. Использование кластера CouchDB в Hyperledger Fabric

Начнем.

1. Организация необходимых файлов конфигурации

Это файл docker-compose, который нам нужно использовать для настройки кластера CouchDB:

version: ‘3’
networks:
  fabric:
          external:
                  name: example
services:
  couchdb1.example.com:
  container_name: couchdb1.example.com
  image: hyperledger/fabric-couchdb:amd64–0.4.15
  environment:
     - COUCHDB_SECRET=0123456789
     - NODENAME=couchdb1.example.com
     - ERL_FLAGS=-setcookie “brumbrum”
     - COUCHDB_QUERY_SERVER_JAVASCRIPT=”/usr/bin/couchjs -S 8589934592 /usr/share/server/main.js”
  volumes:
      - /data/couchdb1:/opt/couchdb/data
  ports:
    - “5001:5984”
  networks:
    - fabric
  couchdb2.example.com:
    container_name: couchdb2.example.com
    image: hyperledger/fabric-couchdb:amd64–0.4.15
    environment:
       - COUCHDB_SECRET=0123456789
       - NODENAME=couchdb2.example.com
       - ERL_FLAGS=-setcookie “brumbrum” 
       - COUCHDB_QUERY_SERVER_JAVASCRIPT=”/usr/bin/couchjs -S 8589934592 /usr/share/server/main.js”
    volumes:
       - /data/couchdb2:/opt/couchdb/data
    ports:
       - “5002:5984”
    networks:
       - fabric
  couchdb3.example.com:
    container_name: couchdb3.example.com
    image: hyperledger/fabric-couchdb:amd64–0.4.15
    environment:
       - COUCHDB_SECRET=0123456789
       - NODENAME=couchdb3.example.com
       - ERL_FLAGS=-setcookie “brumbrum”
       - COUCHDB_QUERY_SERVER_JAVASCRIPT=”/usr/bin/couchjs -S 8589934592 /usr/share/server/main.js”
               volumes:
       - /data/couchdb3:/opt/couchdb/data
    ports:
       - “5003:5984”
    networks:
       - fabric

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

docker-compose up -d

Мы можем проверить это, запустив docker ps. Результат должен выглядеть так:

2. Настройка кластера CouchDB

Для завершения настройки диванного кластера нам необходимо выполнить следующие шаги:

›› Шаг 1: Чтобы настроить CouchDB в кластере, нам нужно открыть веб-интерфейс Fauxton. Доступ к нему можно получить по этой ссылке.

›› Шаг 2. Мы нажимаем кнопку Настроить кластер.

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

Здесь мы используем admin как имя пользователя и пароль (что вы, конечно, не сделаете на практике).

›› Шаг 3. Мы указываем количество узлов, которые мы настраиваем для этого кластера. Здесь мы дали 3.

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

›› Шаг 4. Нажмите кнопку Настроить кластер, и Фокстон завершит настройку кластера.

3. Проверка настройки кластера CouchDB

Чтобы проверить, завершена ли настройка кластера и все ли узлы синхронизированы, нам необходимо выполнить следующие команды:

›› Шаг 1. Чтобы проверить членство в кластере, нам нужно нажать конечную точку _membership:

curl http://username:password@localhost:5984/_membership

Вот пример ожидаемого результата:

{"all_nodes": ["couchdb@couchdb1","[email protected]","[email protected]"],"cluster_nodes":["couchdb@couchdb1","[email protected]","[email protected]"]}

›› Шаг 2: Чтобы проверить состояние настройки кластера, нам нужно нажать конечную точку _cluster_setup.

curl http://admin:admin@localhost:5984/_cluster_setup

Вот как должен выглядеть ожидаемый результат:

{"state":"cluster_finished"}

Мы также можем проверить состояние настройки из интерфейса Fauxton:

4. Важные параметры конфигурации

В файле yaml вы, вероятно, заметили ряд параметров, которые мы использовали для настройки кластера.

Вот некоторые из важных моментов, которые необходимо понять:

• COUCHDB_SECRET
  Устанавливает секретный идентификатор, который, как ожидается, будет использоваться всеми узлами кластера CouchDB. Путь к этому `/opt/couchdb/etc/local.d/docker.ini
• NODENAME
  Внутри контейнера нам нужно задать имя узла CouchDB. Читается как couchdb@${NODENAME}`.
  Путь к этому `/opt/couchdb/etc/vm.args`.
• ERL_FLAGS
  Этот ключ также является идентификатором, который будет общим для всех узлов в кластере CouchDB. Когда какой-либо узел пытается повторно присоединиться к кластеру, значение этого ключа подтверждает, был ли он изначально частью кластера или нет.
• COUCHDB_QUERY_SERVER_JAVASCRIPT
  По умолчанию выделение памяти времени выполнения для обработки запросов с помощью параметра couchjs установлено на 64 МБ.

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

5. Использование кластера CouchDB в Hyperledger Fabric

Мы должны обновить значения следующих переменных env в следующем одноранговом контейнере: CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS

Вместо того, чтобы указывать на один узел CouchDB, он должен указывать на все, что используется для балансировки нагрузки трафика в кластере CouchDB, например балансировщик нагрузки HAProxy® или URL-адрес AWS Elastic Load Balancer.

Эту кластерную настройку также можно использовать, если мы намерены обеспечить поддержку нескольких регионов. Мы можем хранить разные узлы кластера CouchDB в разных регионах (например, в облачном развертывании).

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

Заключение

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

Мы надеемся, что вы нашли эту тему и ее объяснение интересными и полезными.

Hyperledger Fabric - это проект, поддерживаемый Linux Foundation®, и Hyperledger является его зарегистрированным товарным знаком. Apache CouchDB и CouchDB являются товарными знаками Apache Software Foundation. AWS является товарным знаком Amazon.com, Inc. или ее дочерних компаний в США и / или других странах. Docker является товарным знаком или зарегистрированным товарным знаком Docker, Inc. в США и / или других странах.

DLT Labs является товарным знаком DLT Global, Inc.

Автор - Дипак Сингх, DLT Labs ™

Об авторе: Дипак в настоящее время работает с командой DL Tools и любит разбираться в коде и алгоритмах на элементарном уровне.