Una migliori prassi per la resilienza

In questo argomento vengono descritte le procedure ottimali per mantenere un funzionamento continuo nel caso in cui una singola virtual machine (VM) di un'istanza della forma Enterprise di Oracle Blockchain Platform venga messa fuori linea per manutenzione o non riesca in modo imprevisto.

I passi riportati di seguito si applicano solo alle istanze di Oracle Blockchain Platform basate sulla forma Enterprise (non sulla forma Standard). Inoltre, questa guida si applica solo ai seguenti modelli di distribuzione:

• Un'unica organizzazione fondatrice
• Un fondatore con una o più organizzazioni partecipanti

Poiché le istanze di Oracle Blockchain Platform basate sulla forma Standard eseguono tutti i componenti (peer, ordini e servizi di piattaforma) su una singola VM, l'intera istanza diventa non disponibile se una VM non riesce o deve essere arrestata per manutenzione. Non è previsto alcun isolamento nei domini di disponibilità o nei domini di errore. Non utilizzare istanze basate sulla forma Standard per gli ambienti di produzione.

Utilizzare invece le istanze basate sulla forma Enterprise per gli ambienti di produzione. Tali istanze offrono una scalabilità indipendente dei componenti di Hyperledger Fabric e configurazioni di capacità superiore. Le istanze di forma aziendali distribuiscono automaticamente peer, ordini e componenti della piattaforma in domini di disponibilità e domini di errore per fornire isolamento degli errori a livello di infrastruttura. Per usufruire di questo comportamento e garantire l'alta disponibilità, utilizzare le procedure ottimali descritte nelle sezioni seguenti.

Criteri di approvazione

Per una rete con una singola organizzazione (fondatrice), utilizzare criteri di approvazione che consentono a qualsiasi peer di approvare transazioni disponibili, come OR('Founder.member') o OutOf(1, 'Founder.member'). Distribuisci almeno due peer per l'organizzazione fondatrice.

Per una rete con un fondatore e un'organizzazione partecipante, in genere è possibile utilizzare la seguente politica: OutOf(1, 'Founder.member', 'Participant1.member'). Per una configurazione più rigorosa, solo se esiste una ridondanza, è possibile utilizzare OutOf(2, 'Founder.member', 'Participant1.member'). Evitare criteri rigorosi come AND('Founder.member', 'Participant1.member') a meno che entrambe le organizzazioni non dispongano di una ridondanza peer sufficiente.

Per ulteriori informazioni, vedere Specificare un criterio di approvazione.

Distribuzione pari livello

Distribuisci almeno due peer per organizzazione. Oracle Blockchain Platform distribuisce automaticamente i peer tra i domini di disponibilità e i domini di errore per garantire che almeno un peer rimanga disponibile dopo un errore della VM.

Raccolte di dati privati

Se si utilizzano raccolte dati private, impostare il valore Peer Required (requiredPeerCount) su uno o più valori e impostare il valore Numero massimo peer (maxPeerCount) su due o più valori nella definizione della raccolta dati privata. Assicurati che almeno due peer siano membri di ogni raccolta di dati privati e che il commit dei dati privati venga eseguito su almeno due peer. Il valore Peers Required è il numero minimo di peer (escluso il peer di convalida) che devono ricevere correttamente i dati privati prima che la proposta di transazione venga considerata completata.

Per le raccolte di dati private tra organizzazioni, configura il conteggio peer richiesto in modo che sia maggiore del numero di peer di una singola organizzazione e garantisca la distribuzione tra più organizzazioni e VM.

Per ulteriori informazioni, vedere Aggiungi raccolte dati private.

Servizio ordinazione zattera

Utilizzare il servizio di ordinazione Raft a tre nodi predefinito. Oracle Blockchain Platform distribuisce gli ordini tra domini di disponibilità e domini di errore, consentendo al servizio di gestione degli ordini di gestire un guasto a un singolo nodo.

Peer di ancoraggio

Nelle reti con più organizzazioni, configurare almeno un peer di ancoraggio per organizzazione. Per migliorare la resilienza, configura almeno due anchor peer per organizzazione. I peer di ancoraggio sono necessari solo quando nella rete esiste più di un'istanza dell'organizzazione Oracle Blockchain Platform, in quanto consentono comunicazioni basate su pettegolezzi e peer discovery in diverse organizzazioni.

Per ulteriori informazioni, vedere Aggiungere un peer di ancoraggio.

Distribuzione codice concatenato

Per garantire la continuità se un peer non è più disponibile, installare e approvare il codice concatenato su almeno due peer per organizzazione. È possibile distribuire queste distribuzioni in tutte le istanze di Oracle Blockchain Platform in una rete se i requisiti di privacy lo consentono.

Connettività client

Configurare le applicazioni client in modo che non vengano mai applicate a peer specifici. Consentire invece alla libreria client di base di gestire la selezione peer.

Database di stato fallback

Il database di stato viene memorizzato su ogni peer per tutti i canali a cui è unito il peer. Se una VM non riesce, il database di stato locale su tale peer diventa non disponibile fino al ripristino del peer. Oracle Blockchain Platform supporta un modello di database di stato ibrido, in cui un Oracle Database esterno funge da database di stato di fallback (secondario). Quando il database di stato di fallback è abilitato, i dati di stato vengono resi persistenti al di fuori della VM peer in un database che può assumere il ruolo di database di stato primario in base alle esigenze, migliorando così la durabilità e il recupero.

Completare i passi riportati di seguito per utilizzare questa funzione per migliorare la resilienza.

• Abilita il database di stato di fallback per i carichi di lavoro di produzione o critici
• Distribuisci Oracle Database indipendentemente dalle VM peer.
• Configurare Oracle Database per l'alta disponibilità.

Effettuando questi passi è possibile assicurarsi che i dati di stato non siano collegati al ciclo di vita di una singola VM. Il database di stato di fallback funziona in integrazione con la ridondanza peer per gli scenari in cui una singola VM non riesce.

Per ulteriori informazioni, vedere Creazione del database di stato di fallback.