
Introduzione
La tecnologia blockchain ha cambiato le regole del gioco in un sacco di settori, offrendo capacità di archiviazione decentralizzate e immutabili che risolvono problemi di vecchia data nel campo dell'integrità e dell'affidabilità dei dati.
Tra i tanti framework blockchain disponibili, Hyperledger Fabric si è fatto notare come uno dei migliori per le blockchain autorizzate, apprezzato soprattutto per la sua modularità, flessibilità e prontezza per le aziende.
Questa guida dettagliata spiega come creare un setup multi-cluster Hyperledger Fabric, costruendo una rete Hyperledger Fabric multi-cluster e multi-organizzazione.
Distribuendo i componenti di rete tra diversi cluster e organizzazioni, si ottiene una migliore tolleranza ai guasti, capacità di scalabilità e autonomia organizzativa.
Ogni fase è stata spiegata nei dettagli per dare sia approfondimenti tecnici che consigli pratici per l'implementazione.
Comprendere l'architettura multi-cluster Hyperledger Fabric
Prima di iniziare il percorso di implementazione, è fondamentale capire le basi architetturali presentate in questa guida all'architettura Hyperledger Fabric.
Il design multi-cluster è un design sofisticato per l'implementazione di reti blockchain che unisce la collaborazione all'indipendenza organizzativa.
In questo modello architettonico, abbiamo a che fare con due diverse organizzazioni, ognuna delle quali ha la propria Autorità di Certificazione che si occupa di gestire le identità crittografiche e garantire un'autenticazione sicura.
Queste organizzazioni funzionano in modo indipendente, con le loro risorse che girano su diversi cluster Kubernetes Hyperledger Fabric.
Questa separazione offre vantaggi importanti come la tolleranza agli errori, l'isolamento delle risorse e il fatto che ogni organizzazione può mantenere il controllo sulla propria infrastruttura.
Il cluster è impostato in modo che ogni organizzazione abbia il proprio gruppo di peer e l'autorità di certificazione nei propri ambienti dedicati.
Questa scelta di progettazione assicura che non ci siano conflitti di risorse e permette anche alle organizzazioni di adattare la loro infrastruttura in base alle loro esigenze specifiche senza influire sugli altri partecipanti alla rete.
Il servizio di ordinazione, che è il meccanismo di consenso della rete, è distribuito in modo strategico in diverse organizzazioni.
Mettendo due ordinatori in cluster separati, l'architettura ha ridondanza e alta disponibilità.
Se uno degli ordinatori ha problemi, la rete continua a funzionare attraverso l'altro ordinatore, in modo da non interrompere mai il funzionamento.
Questo tipo di struttura permette a ogni organizzazione di avere il controllo totale sulle proprie risorse, offrendo allo stesso tempo un modo per comunicare tra le organizzazioni attraverso canali condivisi e contratti intelligenti.
Strumenti usati
L'implementazione usa strumenti scelti con cura che rendono più facile mettere in funzione sistemi complessi e aggiungono solide capacità di gestione.
EKS rende facile distribuire, gestire e scalare i cluster Kubernetes sull'infrastruttura Amazon Web Services, offrendo una piattaforma affidabile e collaudata per ospitare i componenti di rete Fabric.
La natura gestita di EKS significa che riduce il sovraccarico associato al funzionamento del sistema, offrendo al contempo un'affidabilità di livello aziendale.
Hlf-Operator è un operatore Kubernetes speciale fatto apposta per gestire l'implementazione della rete Hyperledger Fabric e le operazioni continue per le reti Hyperledger Fabric.
Questo operatore semplifica un sacco di cose complicate che servono per mettere in piedi e gestire le reti Fabric e offre un sacco di opzioni di configurazione che rendono l'amministrazione della rete molto più facile e riducono il rischio di errori di configurazione.
Passaggi per configurare la rete
Una volta capito come funziona l'architettura e quali strumenti usare, il processo di implementazione segue una serie di passaggi strutturati che si basano l'uno sull'altro per creare una rete che funziona alla grande.
Passaggio 1: Configurazione del cluster EKS
La prima fase dell'implementazione prevede la creazione dei cluster Kubernetes in cui risiederanno i componenti della rete Fabric.
Questo passaggio fondamentale richiede un'attenta pianificazione per assicurarsi che i cluster siano configurati nel modo giusto per i carichi di lavoro della blockchain.
La configurazione del cluster inizia con la definizione dei parametri che determineranno il comportamento e la capacità del cluster.
Questi parametri includono:
- •Scegli i tipi di istanza in base a quello che pensi sarà il carico di lavoro.
- •Numero di istanze necessarie per gestire i volumi di transazioni previsti
- •Scegli le zone di disponibilità per avere la massima resilienza e ridurre al minimo la latenza
Usando eksctl, uno speciale strumento da riga di comando fatto apposta per gestire i cluster EKS, i cluster vengono creati come da specifiche.
Questo strumento semplifica un sacco di cose complicate che servono per preparare i cluster, assicurando che si seguano le migliori pratiche.
Dopo aver creato i cluster, vengono generati dei file kubeconfig per poter accedere in modo sicuro ai cluster appena creati.
Questi file di configurazione hanno le credenziali di autenticazione e le informazioni di connessione che servono per i prossimi passaggi dell'implementazione.
Passaggio 2: Installa Hlf-Operator e Istio
Una volta che i cluster sono attivi e funzionanti, il passo successivo è installare gli strumenti di gestione che serviranno per facilitare l'implementazione dei componenti Fabric e la comunicazione tra i servizi.
L'installazione di Hlf-Operator inizia con l'aggiunta del repository Helm che contiene i grafici dell'operatore.
Una volta che il repository è pronto, l'operatore viene installato su entrambi i cluster, fornendo le definizioni delle risorse personalizzate e i controller necessari per gestire i componenti Fabric.
Segue l'installazione di Istio, che porta le funzionalità del service mesh ai cluster.
Istio offre alcune funzionalità avanzate di gestione del traffico, bilanciamento del carico e osservabilità che sono molto utili nelle reti blockchain distribuite, dove è fondamentale avere una comunicazione affidabile tra i componenti.
Dopo aver installato Istio, è importante recuperare l'URL esterno fornito dal gateway di ingresso Istio. Questo URL, che si trova nella colonna EXTERNAL-IP nella query dei servizi Istio, è l'endpoint pubblico del cluster e verrà usato spesso nella configurazione DNS.
Passaggio 3: configurare il DNS
La configurazione del Domain Name System definisce la struttura di denominazione che permette una facile comunicazione tra i componenti di rete distribuiti su diversi cluster.
Per configurare il DNS, devi creare una zona ospitata in AWS Route 53 per il dominio che vuoi collegare alla rete Fabric.
All'interno di questa zona ospitata, ci sono record individuali per ogni componente del servizio che mappa i nomi di dominio leggibili dall'utente all'endpoint del cluster.
Per ogni peer, autorità di certificazione e ordinante, viene impostato un record CNAME che punta all'URL esterno del cluster appropriato.
Questa configurazione permette ai componenti di un cluster di trovare e comunicare con i componenti di altri cluster usando nomi di dominio coerenti e prevedibili.
Struttura dei record DNS:
- •Per la prima organizzazione, vengono creati dei record per l'autorità di certificazione e i peer
- •La seconda organizzazione deve avere il proprio set di registrazioni
- •L'organizzazione che fa l'ordine ha bisogno di registrazioni per la sua Autorità di Certificazione e per più ordinanti che puntano ai rispettivi endpoint del cluster.
Passaggio 4: Configurazione delle CA e dei peer dell'organizzazione
Una volta che l'infrastruttura e la rete sono pronte, l'implementazione dei componenti Fabric inizia con le autorità di certificazione e i peer di ogni organizzazione.
Le autorità di certificazione sono il punto di riferimento per le rispettive organizzazioni e rilasciano le identità crittografiche che i partecipanti usano per autenticarsi e autorizzare le azioni all'interno della rete.
Ogni organizzazione implementa la propria CA in base a specifiche che includono credenziali di registrazione, configurazione TLS e altri parametri di sicurezza.
I peer sono i nodi di elaborazione delle transazioni all'interno di ogni organizzazione.
Questi componenti tengono traccia delle copie del registro, eseguono il codice della catena e approvano le transazioni in base alle regole di approvazione della rete.
Sei pronto a lanciare la tua rete blockchain?
Inizia a costruire la tua rete Hyperledger Fabric multi-cluster con la nostra guida e il nostro supporto esperto.
Dettagli sull'implementazione tra pari
Distribuzione peer: per distribuire una CA, vengono specificati i requisiti di archiviazione, l'allocazione delle risorse e le impostazioni di connettività.
Per la prima organizzazione:
- •Prima si installa la CA, poi i nodi peer
- •I file di configurazione specificano i parametri specifici per ciascuno dei componenti, come identità bootstrap, classi di archiviazione e tipi di servizio
- •Dopo aver fatto queste configurazioni, i componenti vengono tenuti d'occhio finché non sono pronti
La seconda organizzazione ha un modello di distribuzione simile, con la sua CA e i suoi peer configurati in base ai requisiti specifici dell'organizzazione.
Anche se il processo generale è simile a quello della prima organizzazione, alcuni valori di configurazione sono diversi per rappresentare le configurazioni separate del cluster e del dominio.
Passaggio 5: Crea l'organizzazione dell'ordinante
L'organizzazione che effettua l'ordine ha un ruolo speciale nella rete, perché fornisce il meccanismo di consenso che viene usato per ordinare le transazioni e creare blocchi da distribuire ai peer.
La creazione della CA dell'ordinante crea l'autorità di certificazione che sarà responsabile dell'emissione delle identità ai nodi dell'ordinante.
Questa CA non ha niente a che fare con le CA dell'organizzazione e rende più chiara la separazione tra l'ordine del servizio e l'approvazione della transazione.
Il primo ordine viene distribuito con la configurazione che dice:
- •Il suo collegamento con la CA dell'ordinante
- •Requisiti di archiviazione
- •Impostazioni del blocco Genesis
Questo ordinatore è il primo punto di riferimento per il servizio di ordinazione.
L'implementazione del secondo ordinatore aggiunge un ulteriore livello di complessità a causa della sua posizione in un cluster separato.
Si usa una soluzione alternativa per creare la configurazione richiesta con una CA già esistente; si fanno modifiche manuali per assicurarsi che chi fa la richiesta sia collegato alla giusta autorità di certificazione.
Dettagli di configurazione dell'ordinante
Sono state apportate modifiche specifiche:
- •Fai in modo che i riferimenti all'host CA puntino al dominio CA dell'ordinante
- •L'host CA viene aggiunto alla richiesta di firma del certificato
- •I certificati CA TLS vengono copiati dalla configurazione del primo ordinante
Queste modifiche servono per permettere al secondo ordinante di autenticarsi e comunicare correttamente con il servizio di ordinazione CA.
Dopo aver sistemato le impostazioni, il secondo ordinatore viene messo in funzione e controllato finché non è pronto.
A questo punto, la rete ha tutti i pezzi dell'infrastruttura principale, con tutte le CA, i peer e gli orderer che funzionano e sono accessibili.
Passaggio 6: Crea un canale
I canali in Hyperledger Fabric offrono vie di comunicazione private tra chi partecipa alla rete, permettendo transazioni riservate e condivisione selettiva dei dati.
La creazione del canale inizia con la registrazione e l'iscrizione delle identità amministrative per ogni organizzazione e l'organizzazione committente.
Queste identità hanno i privilegi necessari per gestire il canale.
Per registrarti devi:
- •Collegarsi alla CA pertinente
- •Creare account utente con attributi amministrativi
Dopo la registrazione, l'iscrizione crea i materiali crittografici per ciascuna delle identità (certificati di firma e chiavi private).
Una volta pronte tutte le identità amministrative, vengono messe insieme in un segreto Kubernetes, che verrà usato durante le operazioni del canale.
Questo segreto raggruppa i materiali crittografici necessari per la governance del canale.
Il canale principale è impostato con delle specifiche che dicono:
- •Organizzazioni che partecipano
- •Gli ordinanti sono responsabili del canale
- •Regole che gestiscono come funzionano i canali e le modifiche
Questo processo di inizializzazione crea il blocco genesi per il canale e imposta la configurazione del canale.
I colleghi di entrambe le organizzazioni si uniscono al canale facendo riferimento alla configurazione del canale principale e dando le credenziali della loro organizzazione.
Questo processo di unione rende il canale visibile ai peer e permette loro di ricevere i blocchi che contengono le transazioni del canale.
I canali follower vengono creati per ogni organizzazione per collegare i colleghi e il canale.
Queste configurazioni dicono a quale peer deve seguire quale canale e completano l'impostazione dell'appartenenza alla catena.
Passaggio 7: Installa Chaincode
Chaincode, l'implementazione dello smart contract in Hyperledger Fabric, è la logica di business che descrive l'elaborazione delle transazioni e la gestione dello stato sulla blockchain.
Il ciclo di vita del chaincode inizia con il confezionamento del chaincode come artefatto distribuibile.
In questa implementazione, il chaincode viene distribuito come servizio che richiede:
- •Crea un'immagine Docker con il chaincode
- •Preparare i metadati di connessione che spiegano come i peer devono connettersi al servizio chaincode.
Per la prima organizzazione:
- •Il chaincode impacchettato viene installato sul peer, rendendo il pacchetto chaincode disponibile per l'implementazione
- •Viene preparato un file di configurazione della connessione che include l'indirizzo e i dettagli della connessione TLS per il servizio chaincode
- •Il chaincode viene poi distribuito come servizio Kubernetes nel cluster dell'organizzazione, rendendolo accessibile ai colleghi dell'organizzazione.
Dopo che la definizione del chaincode è stata implementata, l'organizzazione la approva, dicendo che è pronta per usare questa versione del chaincode sul canale.
Dopo che tutte le organizzazioni hanno dato l'ok alla definizione del chaincode, questo viene inviato al canale, che lo rende attivo e pronto per essere usato.
Questo processo di impegno crea il contenitore chaincode e lo rende l'implementazione ufficiale per il canale.
La seconda organizzazione segue un processo di installazione simile e installa lo stesso pacchetto chaincode sui propri peer e distribuisce il servizio chaincode nel proprio cluster.
Dopo l'installazione e la distribuzione, il chaincode è pronto per essere usato in tutta la rete.
Passaggio 8: controlla che la rete funzioni
Una volta che tutti i componenti sono stati implementati e configurati, la verifica assicura che la rete funzioni come previsto e possa elaborare correttamente le transazioni.
Il test delle transazioni consiste nell'avviare transazioni campione che mettono alla prova la logica del chaincode.
Queste transazioni sono:
- •Inviato ai colleghi, che simulano l'esecuzione della transazione e restituiscono le approvazioni alla transazione
- •Invia al servizio di ordinamento che li mette in blocchi e li manda a tutti i membri del canale
L'elaborazione corretta delle transazioni garantisce che:
- •La comunicazione peer-to-peer funziona bene
- •Le politiche di approvazione sono applicate come si deve
- •Il servizio di ordinazione mette in ordine le transazioni nel modo giusto
- •Le modifiche di stato vengono riportate correttamente su tutti i peer
Conclusione
Creare una rete Hyperledger Fabric multi-cluster e multi-organizzazione richiede una pianificazione attenta, una configurazione precisa e il coordinamento di tanti componenti e strumenti.
Il processo include:
- •Costruire infrastrutture isolate ma collegate
- •Implementare elementi blockchain specifici
- •Metti in piedi dei canali di comunicazione sicuri
- •Verifica del corretto funzionamento attraverso il test delle transazioni
Questo approccio all'architettura offre i seguenti vantaggi:
- •Migliorata la tolleranza agli errori distribuendo i componenti sulla rete
- •Migliorata la scalabilità separando le risorse organizzative
- •Maggiore controllo organizzativo sull'infrastruttura e sulle operazioni
- •Più flessibilità per adattare la rete man mano che le esigenze cambiano
L'infrastruttura blockchain che ne viene fuori è una base solida che può essere usata per un sacco di casi d'uso in diversi settori, dal monitoraggio della catena di approvvigionamento ai regolamenti finanziari fino alla gestione delle cartelle cliniche.
La natura autorizzata di Hyperledger Fabric, insieme all'architettura multi-cluster, offre una piattaforma che bilancia la trasparenza e l'immutabilità della blockchain con i requisiti di privacy e controllo delle app aziendali.
Lavoro futuro
Ci sono un sacco di miglioramenti che si potrebbero fare per rendere ancora più efficiente il processo di implementazione e dare più possibilità all'architettura di rete.
L'automazione è una grande occasione per migliorare.
Gli script di sviluppo e i modelli di infrastruttura come codice potrebbero essere usati per:
- •Semplifica il processo di configurazione
- •Riduci al minimo i passaggi di configurazione manuale
- •Cerca di ridurre al minimo la possibilità di errori umani
Questa automazione permetterebbe di implementare la rete in modo più ripetibile e di renderla disponibile a organizzazioni con diversi livelli di familiarità con la blockchain.
Aumentare il supporto per le distribuzioni multi-cloud renderebbe la rete più resistente e flessibile.
Mettere diverse organizzazioni su diversi cloud provider, tipo una su AWS, un'altra su Google Cloud Platform e una terza su Microsoft Azure, farebbe sì che non ci siano dipendenze tra i singoli cloud, ma che le organizzazioni possano usare i loro ambienti cloud preferiti pur continuando a far parte di una rete blockchain unificata.
Questi miglioramenti si baserebbero sulle solide fondamenta dell'attuale implementazione, ampliando le capacità della rete e rendendola ancora più adatta alle implementazioni aziendali di produzione.


