Meilleures pratiques pour la résilience
Cette rubrique décrit les meilleures pratiques pour maintenir le fonctionnement continu en cas de mise hors ligne d'une seule machine virtuelle d'une instance de forme Enterprise d'Oracle Blockchain Platform pour maintenance ou de défaillance inattendue.
- Une seule organisation fondatrice
- Un fondateur avec une ou plusieurs organisations participantes
Utilisez plutôt des instances basées sur la forme Enterprise pour les environnements de production. Ces instances fournissent une mise à l'échelle indépendante des composants Hyperledger Fabric et des configurations de capacité supérieure. Les instances de forme d'entreprise répartissent automatiquement les pairs, les responsables des commandes et les composants de la plate-forme dans les domaines de disponibilité et les domaines d'erreur pour assurer un isolement des pannes au niveau de l'infrastructure. Pour tirer parti de ce comportement et garantir une haute disponibilité, utilisez les meilleures pratiques décrites dans les sections suivantes.
Politiques d'endossement
Pour un réseau avec une seule organisation (fondatrice), utilisez des politiques d'endossement qui permettent à tout pair disponible d'endosser des transactions, telles que OR('Founder.member') ou OutOf(1, 'Founder.member'). Déployez au moins deux pairs pour l'organisation fondatrice.
Pour un réseau avec un fondateur et une organisation participante, vous pouvez généralement utiliser la politique suivante : OutOf(1, 'Founder.member', 'Participant1.member'). Pour une configuration plus stricte, vous pouvez utiliser OutOf(2, 'Founder.member', 'Participant1.member') uniquement s'il existe une redondance. Évitez les politiques strictes telles que AND('Founder.member', 'Participant1.member') sauf si les deux organisations disposent d'une redondance de pairs suffisante.
Pour plus d'informations, voir Spécifier une politique d'endossement.
Déploiement de pair
Déployez au moins deux pairs par organisation. Oracle Blockchain Platform répartit automatiquement les pairs dans les domaines de disponibilité et les domaines d'erreur afin de garantir qu'au moins un pair reste disponible après une défaillance de machine virtuelle.
Collections de données privées
Si vous utilisez des collections de données privées, réglez la valeur Pairs Required (Pairs requis) (requiredPeerCount) à un ou plusieurs, et réglez la valeur Max Peer Peer Count (Nombre maximal de pairs) (maxPeerCount) à deux ou plus dans la définition de la collecte de données privée. Assurez-vous qu'au moins deux pairs sont membres de chaque collecte de données privée et que les données privées sont validées entre au moins deux pairs. La valeur Pairs requis est le nombre minimal de pairs (à l'exclusion du pair d'endossement) qui doivent recevoir avec succès les données privées avant que la proposition de transaction ne soit considérée comme terminée.
Pour les collections de données privées interorganisations, configurez le nombre de pairs requis pour qu'il soit supérieur au nombre de pairs d'une seule organisation et assurez la distribution entre plusieurs organisations et machines virtuelles.
Pour plus d'informations, voir Ajouter des collections de données privées.
Service de commande Raft
Utilisez le service de commande Raft à trois noeuds par défaut. Oracle Blockchain Platform répartit les responsables des commandes entre les domaines de disponibilité et les domaines d'erreur, ce qui permet au service de commande de gérer une défaillance de noeud unique.
Pairs d'ancrage
Dans les réseaux comportant plusieurs organisations, configurez au moins un pair d'ancrage par organisation. Pour une meilleure résilience, configurez au moins deux pairs d'ancrage par organisation. Des pairs ancrés ne sont nécessaires que lorsqu'il existe plus d'une instance d'organisation Oracle Blockchain Platform dans le réseau, car ils permettent une communication basée sur des potins et une détection de pairs dans différentes organisations.
Pour plus d'informations, voir Ajouter un pair d'ancrage.
Déploiement de code de chaîne
Pour assurer la continuité en cas de non-disponibilité d'un pair, installer et approuver le code de chaîne sur au moins deux pairs par organisation. Vous pouvez répartir ces déploiements entre les instances Oracle Blockchain Platform d'un réseau si vos exigences en matière de confidentialité le permettent.
Connectivité client
Configurez les applications client pour qu'elles ne soient jamais verrouillées vers des pairs spécifiques. Au lieu de cela, permettez à la bibliothèque client sous-jacente de gérer la sélection des pairs.
Base de données d'état de secours
La base de données d'état est stockée sur chaque pair pour tous les canaux auxquels le pair est joint. En cas d'échec d'une machine virtuelle, la base de données d'état local sur ce pair devient indisponible jusqu'à ce que le pair soit restauré. Oracle Blockchain Platform prend en charge un modèle de base de données à état hybride, où une base de données Oracle Database externe agit comme base de données à état secondaire. Lorsque la base de données d'état de secours est activée, les données d'état sont conservées en dehors de la machine virtuelle pair dans une base de données qui peut prendre le relais en tant que base de données d'état principale si nécessaire, ce qui améliore la durabilité et la récupération.
- Activer la base de données d'état de secours pour les charges de travail de production ou les charges de travail critiques
- Déployez Oracle Database indépendamment des machines virtuelles pairs.
- Configurer Oracle Database pour la haute disponibilité.
Pour plus d'informations, voir Créer la base de données d'état de secours.