Introducción
La tecnología blockchain ha supuesto un cambio revolucionario en muchos sectores, ya que ofrece capacidades de registro descentralizadas e inmutables que resuelven problemas ancestrales en el ámbito de la integridad y la confianza de los datos.
Entre los muchos marcos de cadena de bloques disponibles, Hyperledger Fabric se ha convertido en una de las principales implementaciones de cadena de bloques con permiso, especialmente apreciada por su modularidad, flexibilidad y preparación para la empresa.
Esta guía detallada profundiza en el complejo proceso de creación de una configuración multiclúster de Hyperledger Fabric, construyendo una red Hyperledger Fabric multiclúster y multiorganización.
Al distribuir los componentes de la red entre diferentes clústeres y organizaciones, se consigue una mayor tolerancia a fallos, capacidad de escalado y autonomía organizativa.
Cada paso se ha detallado cuidadosamente para proporcionar tanto profundidad técnica como conocimientos prácticos para la implementación.
Comprensión de la arquitectura Hyperledger Fabric multiclúster
Antes de comenzar el proceso de implementación, es fundamental comprender los fundamentos arquitectónicos que se presentan en esta guía de arquitectura de Hyperledger Fabric.
El diseño multiclúster es un diseño sofisticado para la implementación de redes blockchain que combina la colaboración con la independencia organizativa.
En este modelo arquitectónico, tratamos con dos organizaciones diferentes, cada una de las cuales tiene su propia autoridad de certificación que se encarga de gestionar las identidades criptográficas y garantizar una autenticación segura.
Estas organizaciones funcionan de forma independiente, y sus recursos se ejecutan en diferentes clústeres de Kubernetes Hyperledger Fabric.
Esta separación ofrece importantes ventajas, como la tolerancia a fallos, el aislamiento de recursos y el hecho de que cada organización puede mantener el control sobre su infraestructura.
La configuración del clúster es tal que cada organización aloja su propio grupo de pares y su propia autoridad de certificación en sus propios entornos dedicados.
Esta elección de diseño garantiza que no haya conflictos por los recursos y también permite a las organizaciones ampliar su infraestructura en función de sus necesidades específicas sin afectar a otros participantes de la red.
El servicio de pedidos, que actúa como mecanismo de consenso para la red, se distribuye estratégicamente entre diferentes organizaciones.
Al colocar dos ordenadores en clústeres separados, la arquitectura tiene redundancia y alta disponibilidad.
Si un solicitante tiene problemas, la red sigue funcionando a través del otro solicitante, de modo que nunca deja de funcionar.
Este tipo de arquitectura permite a cada organización mantener un control total sobre sus respectivos recursos, al tiempo que proporciona un medio de comunicación entre organizaciones a través de canales compartidos y contratos inteligentes.
Herramientas utilizadas
La implementación utiliza herramientas cuidadosamente seleccionadas que facilitan el despliegue de sistemas complejos y añaden sólidas capacidades de gestión.
EKS simplifica la implementación, la gestión y el escalado de clústeres de Kubernetes en la infraestructura de Amazon Web Services, proporcionando una plataforma fiable y probada para alojar componentes de red Fabric.
La naturaleza gestionada de EKS significa que reduce la sobrecarga asociada al funcionamiento del sistema, al tiempo que ofrece una fiabilidad de nivel empresarial.
Hlf-Operator representa un operador Kubernetes especializado diseñado específicamente para gestionar la implementación de redes Hyperledger Fabric y las operaciones continuas de las redes Hyperledger Fabric.
Este operador abstrae muchas de las complejas tareas de implementación y gestión asociadas a las redes Fabric y ofrece un conjunto de opciones de configuración declarativas que facilitan enormemente la administración de la red y reducen la posibilidad de errores de configuración.
Pasos para configurar la red
Una vez comprendida la arquitectura e identificadas las herramientas, el proceso de implementación sigue una secuencia estructurada de pasos que se complementan entre sí para crear una red totalmente funcional.
Paso 1: Configuración del clúster EKS
La primera fase de la implementación consiste en crear los clústeres de Kubernetes donde residirán los componentes de la red Fabric.
Este paso fundamental implica una planificación cuidadosa para garantizar que los clústeres estén configurados adecuadamente para las cargas de trabajo de la cadena de bloques.
La configuración del clúster comienza con la definición de los parámetros que regirán el comportamiento y la capacidad del clúster.
Estos parámetros incluyen:
- •Tipos de instancias que se eligen en función de las características previstas de la carga de trabajo.
- •Número de instancias necesarias para gestionar los volúmenes de transacciones previstos.
- •Zonas de disponibilidad elegidas para maximizar la resiliencia y minimizar la latencia.
Mediante eksctl, una herramienta especial de línea de comandos diseñada para la gestión de clústeres EKS, los clústeres se crean según las especificaciones definidas.
Esta herramienta automatiza gran parte de la complejidad asociada al aprovisionamiento de clústeres, al tiempo que garantiza el cumplimiento de las mejores prácticas.
Tras la creación de los clústeres, se generan archivos kubeconfig para permitir el acceso seguro a los clústeres recién creados.
Estos archivos de configuración incluyen las credenciales de autenticación y la información de conexión necesarias para los siguientes pasos de implementación.
Paso 2: Instalar Hlf-Operator e Istio
Una vez que los clústeres estén en funcionamiento, la siguiente etapa es la instalación de las herramientas de gestión que se utilizarán para facilitar la implementación de los componentes de Fabric y la comunicación entre servicios.
La instalación de Hlf-Operator comienza añadiendo el repositorio Helm que contiene los gráficos del operador.
Una vez que el repositorio está disponible, el operador se instala en ambos clústeres, proporcionando las definiciones de recursos personalizados y los controladores necesarios para la gestión de los componentes de Fabric.
A continuación se realiza la instalación de Istio, que aporta las capacidades de la malla de servicios a los clústeres.
Istio permite algunas funciones avanzadas de gestión del tráfico, equilibrio de carga y observabilidad que resultan muy útiles en redes blockchain distribuidas, donde es muy importante contar con una comunicación fiable entre los componentes.
Después de instalar Istio, es importante recuperar la URL externa proporcionada por la puerta de enlace de entrada de Istio. Esta URL, que aparece en la columna EXTERNAL-IP de la consulta de los servicios de Istio, es el punto final público del clúster y se utilizará ampliamente en la configuración del DNS.
Paso 3: Configurar el DNS
La configuración del Sistema de Nombres de Dominio define la estructura de nomenclatura que permite una comunicación fluida entre los componentes de red distribuidos en diferentes clústeres.
La configuración del DNS requiere la creación de una zona alojada en AWS Route 53 para que el dominio se asocie a la red Fabric.
Dentro de esta zona alojada, se configuran registros individuales para cada componente del servicio que asigna los nombres de dominio legibles por humanos al punto final del clúster.
Para cada uno de los pares, la autoridad de certificación y el solicitante, se establece un registro CNAME que apunta a la URL externa del clúster correspondiente.
Esta configuración permite a los componentes de un clúster encontrar y comunicarse con componentes de otros clústeres utilizando nombres de dominio coherentes y predecibles.
Estructura de los registros DNS:
- •Para la primera organización, se crean registros para la autoridad de certificación y los pares.
- •La segunda organización debe tener su propio conjunto de registros.
- •La organización solicitante requiere registros para su autoridad de certificación y múltiples solicitantes que apunten a sus respectivos puntos finales de clúster.
Paso 4: Configuración de las CA y los pares de la organización
Una vez que la infraestructura y la red están listas, la implementación de los componentes reales de Fabric comienza con las autoridades de certificación y los pares de cada organización.
Las autoridades de certificación son los pilares de confianza de sus respectivas organizaciones y emiten las identidades criptográficas que los participantes utilizan para autenticarse y autorizar acciones dentro de la red.
Cada organización implementa su CA basándose en especificaciones que incluyen credenciales de inscripción, configuración TLS y otros parámetros de seguridad.
Los pares son los nodos de procesamiento de transacciones dentro de cada organización.
Estos componentes guardan copias del libro mayor, ejecutan el código de cadena y respaldan las transacciones basándose en las políticas de respaldo de la red.
¿Listo para implementar tu red blockchain?
Empieza a crear tu red Hyperledger Fabric multiclúster con nuestra orientación y asistencia expertas.
Detalles de la implementación por pares
Implementación por pares: para implementar una CA, se especifican los requisitos de almacenamiento, la asignación de recursos y la configuración de conectividad.
Para la primera organización:
- •Primero se implementa la CA y, a continuación, los nodos pares.
- •Los archivos de configuración especifican los parámetros específicos para cada uno de los componentes, como identidades de arranque, clases de almacenamiento y tipos de servicio.
- •Tras la aplicación de estas configuraciones, los componentes se supervisan hasta que se encuentran en estado listo.
La segunda organización tiene un patrón de implementación similar, con su CA y sus pares configurados de acuerdo con los requisitos específicos de la organización.
Aunque el proceso general es similar al de la primera organización, algunos valores de configuración difieren para representar las configuraciones separadas del clúster y del dominio.
Paso 5: Crear la organización del solicitante.
La organización solicitante tiene un papel especial en la red, ya que proporciona el mecanismo de consenso que se utiliza para secuenciar las transacciones y crear bloques que se distribuirán a los pares.
La creación de la CA del solicitante crea la autoridad de certificación que se encargará de emitir identidades a los nodos solicitantes.
Esta CA está desvinculada de las CA de la organización y refuerza la separación entre el servicio de pedidos y la aprobación de transacciones.
El primer pedido se implementa con la configuración que especifica:
- •Tu conexión con la CA solicitante.
- •Requisitos de almacenamiento
- •Configuración del bloque Génesis.
Este solicitante es el primer punto de referencia para el servicio de pedidos.
La implementación del segundo ordenador añade un nivel adicional de complejidad debido a la ubicación de este ordenador en un clúster independiente.
Se utiliza una solución alternativa para crear la configuración necesaria con una CA existente; se realizan cambios manuales para garantizar que el solicitante esté conectado a la autoridad de certificación correcta.
Detalles de configuración del solicitante
Se realizan cambios específicos:
- •Las referencias del host CA deben apuntar al dominio CA del solicitante.
- •Se añade el host CA a la solicitud de firma de certificado.
- •Los certificados TLS de CA se copian de la configuración del primer solicitante.
Estos ajustes se realizan para permitir que el segundo solicitante se autentique correctamente y se comunique con la CA del servicio de solicitud.
Tras los ajustes de configuración, se implementa el segundo ordenador y se supervisa hasta que esté operativo.
En esta fase, la red cuenta con un conjunto completo de componentes básicos de infraestructura, con todas las CA, pares y ordenadores en funcionamiento y accesibles.
Paso 6: Crear canal
Los canales de Hyperledger Fabric proporcionan vías de comunicación privadas entre participantes específicos de la red, lo que permite flujos de transacciones confidenciales y el intercambio selectivo de datos.
La creación del canal comienza con el registro y la inscripción de las identidades administrativas de cada organización y de la organización solicitante.
Estas identidades tienen los privilegios necesarios para realizar operaciones de gestión de canales.
El proceso de registro requiere:
- •Conectarse a la CA pertinente.
- •Crear cuentas de usuario con atributos administrativos.
Tras el registro, la inscripción crea los materiales criptográficos para cada una de las identidades (certificados de firma y claves privadas).
Una vez que todas las identidades administrativas estén listas, se compilan en un secreto de Kubernetes, al que se hará referencia durante las operaciones del canal.
Este secreto agrupa los materiales criptográficos necesarios para la gobernanza del canal.
El canal principal se inicializa con especificaciones que definen:
- •Organizaciones participantes
- •Los responsables de los pedidos son responsables del canal.
- •Políticas que rigen el funcionamiento y las modificaciones del canal.
Este proceso de inicialización crea el bloque génesis para el canal y crea la configuración para el canal.
Los compañeros de ambas organizaciones se unen al canal haciendo referencia a la configuración del canal principal y aportando las credenciales de su organización.
Este proceso de unión hace que el canal sea visible para los pares y les permite recibir bloques que contienen transacciones del canal.
Se crean canales de seguidores para cada organización con el fin de establecer la conexión entre los pares y el canal.
Estas configuraciones contienen información sobre qué par debe seguir qué canal y completan la configuración de la cadena de membresía.
Paso 7: Instalar el código de cadena
Chaincode, la implementación de contratos inteligentes en Hyperledger Fabric, es la lógica empresarial que describe el procesamiento de transacciones y la gestión del estado en la cadena de bloques.
El ciclo de vida del código de cadena comienza con el empaquetado del código de cadena como un artefacto implementable.
En esta implementación, el código de cadena se implementa como un servicio que requiere:
- •La creación de una imagen Docker que contenga el código de cadena.
- •La preparación de metadatos de conexión que describan cómo deben conectarse los pares al servicio de código de cadena.
Para la primera organización:
- •El chaincode empaquetado se instala en el par, lo que hace que el paquete chaincode esté disponible para su implementación.
- •Se prepara un archivo de configuración de conexión que incluye la dirección y los detalles de conexión TLS para el servicio chaincode.
- •A continuación, el código de cadena se implementa como un servicio de Kubernetes en el clúster de la organización, lo que lo hace accesible a los pares de la organización.
Una vez implementada la definición del código de cadena, la organización aprueba la definición del código de cadena, lo que indica que está lista para utilizar esta versión del código de cadena en el canal.
Una vez que todas las organizaciones hayan aprobado la definición del código de cadena, este se envía al canal, lo que lo activa y lo prepara para su invocación.
Este proceso de compromiso crea el contenedor de código de cadena y lo convierte en la implementación autorizada para el canal.
La segunda organización sigue un proceso de instalación similar e instala el mismo paquete de código de cadena en sus pares e implementa el servicio de código de cadena en su clúster.
Tras la instalación y la implementación, el código de cadena estará listo para su uso en toda la red.
Paso 8: Verificar la funcionalidad de la red
Una vez desplegados y configurados todos los componentes, la verificación garantiza que la red funciona según lo previsto y puede procesar las transacciones correctamente.
Las pruebas de transacciones implican iniciar transacciones de muestra que ejercitan la lógica del código de cadena.
Estas transacciones son:
- •Enviado a tus pares, que simulan la ejecución de la transacción y devuelven los endosos a la transacción.
- •Enviarlos al servicio de pedidos, que los secuenciará en bloques y los enviará a todos los miembros del canal.
El procesamiento correcto de las transacciones garantiza que:
- •La comunicación entre pares funciona correctamente.
- •Las políticas de respaldo se aplican correctamente.
- •El servicio de pedidos secuencia las transacciones de forma adecuada.
- •Los cambios de estado se reflejan correctamente en todos los pares.
Conclusión
La creación de una red Hyperledger Fabric multiclúster y multiorganización requiere una planificación cuidadosa, una configuración meticulosa y la coordinación de muchos componentes y herramientas.
El proceso incluye:
- •Construir una infraestructura aislada pero conectada.
- •Implementar elementos especializados de cadena de bloques.
- •Configuración de canales de comunicación seguros.
- •Comprueba el correcto funcionamiento mediante pruebas de transacciones.
Este enfoque de la arquitectura ofrece las siguientes ventajas:
- •Tolerancia a fallos mejorada mediante la distribución de componentes a través de la red.
- •Mejora de la escalabilidad mediante la separación de los recursos organizativos.
- •Mayor control organizativo sobre la infraestructura y las operaciones.
- •Mayor flexibilidad para adaptar la red a medida que evolucionan los requisitos.
La infraestructura blockchain resultante es una base sólida que se puede utilizar para una variedad de casos de uso en todos los sectores, desde el seguimiento de la cadena de suministro hasta las liquidaciones financieras y la gestión de registros sanitarios.
La naturaleza autorizada de Hyperledger Fabric, junto con la arquitectura multiclúster, proporciona una plataforma que equilibra la transparencia y la inmutabilidad de la cadena de bloques con los requisitos de privacidad y control de las aplicaciones empresariales.
Trabajo futuro
Hay varias mejoras que podrían realizarse para optimizar aún más el proceso de implementación y ampliar las capacidades de la arquitectura de red.
La automatización es una oportunidad importante para mejorar.
El desarrollo de scripts y plantillas de infraestructura como código podría utilizarse para:
- •Simplifica el proceso de configuración.
- •Minimiza la cantidad de pasos de configuración manual.
- •Minimiza la posibilidad de errores humanos.
Esta automatización permitiría implementar la red de forma más repetitiva y ponerla a disposición de organizaciones con diferentes niveles de familiaridad con la cadena de bloques.
Aumentar la compatibilidad con implementaciones multicloud haría que la red fuera más resistente y flexible.
Implementar diferentes organizaciones en diferentes proveedores de nube, como implementar una organización en AWS, otra en Google Cloud Platform y una tercera en Microsoft Azure, garantizaría que no haya dependencias entre nubes individuales, pero que la organización pueda aprovechar sus entornos de nube favoritos sin dejar de participar en una red blockchain unificada.
Estas mejoras se basarían en la sólida base formada por la implementación actual, ampliando las capacidades de la red y haciéndola aún más adecuada para implementaciones empresariales de producción.
