A Meilleures pratiques en matière de 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 à des fins de maintenance ou d'échec inattendu.
- Une seule organisation fondatrice
- 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 homologues, les donneurs d'ordres et les composants de plate-forme entre les domaines de disponibilité et les domaines de pannes afin d'isoler les 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.
Stratégies d'approbation
Pour un réseau avec une seule organisation (fondatrice), utilisez des stratégies d'approbation qui permettent à tout pair disponible d'approuver 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 stratégie suivante : OutOf(1, 'Founder.member', 'Participant1.member'). Pour une configuration plus stricte, uniquement si la redondance existe, vous pouvez utiliser OutOf(2, 'Founder.member', 'Participant1.member'). Evitez les stratégies strictes telles que AND('Founder.member', 'Participant1.member'), sauf si les deux organisations disposent d'une redondance par les pairs suffisante.
Pour plus d'informations, reportez-vous à Spécification d'une stratégie d'approbation.
Déploiement homologue
Déployez au moins deux homologues par organisation. Oracle Blockchain Platform répartit automatiquement les homologues entre les domaines de disponibilité et les domaines de pannes. Au moins un homologue reste disponible en cas de défaillance d'une machine virtuelle.
Collectes de données privées
Si vous utilisez des collectes de données privées, définissez la valeur Pairs requis (requiredPeerCount) sur un ou plusieurs, puis la valeur Nombre maximal d'homologues (maxPeerCount) sur 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 sur au moins deux pairs. La valeur Peers Required est le nombre minimal d'homologues (à l'exception du pair d'approbation) qui doivent recevoir les données privées avant que la proposition de transaction ne soit considérée comme terminée.
Pour les collectes de données privées interorganisations, configurez le nombre d'homologues requis pour qu'il soit supérieur au nombre d'homologues d'une seule organisation et assurez la distribution entre plusieurs organisations et machines virtuelles.
Pour plus d'informations, reportez-vous à Ajout de collections de données privées.
Service de commande de radeau
Utilisez le service de commande Raft à trois noeuds par défaut. Oracle Blockchain Platform répartit les donneurs d'ordre entre les domaines de disponibilité et les domaines de pannes, ce qui permet au service de commande de gérer une panne sur un seul noeud.
Anchor Peers
Dans les réseaux avec plusieurs organisations, configurez au moins un pair d'ancrage par organisation. Pour une meilleure résilience, configurez au moins deux homologues d'ancrage par organisation. Les homologues d'ancrage ne sont nécessaires que lorsque plusieurs instances d'organisation Oracle Blockchain Platform existent sur le réseau, car elles permettent une communication basée sur les commérages et une découverte par les pairs dans différentes organisations.
Pour plus d'informations, voir Ajouter un homologue d'ancrage.
Déploiement de code chaîne
Pour assurer la continuité en cas d'indisponibilité d'un pair, installez et approuvez le code 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é du client
Configurez les applications client pour qu'elles ne s'accrochent jamais à des homologues spécifiques. Au lieu de cela, autorisez la bibliothèque client sous-jacente à 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. Si une machine virtuelle échoue, la base de données d'état locale 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 d'état hybride, dans lequel une base de données Oracle Database externe agit comme une base de données d'état de secours (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 homologue 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 critiques
- Déployez Oracle Database indépendamment des machines virtuelles homologues.
- Configurer Oracle Database pour la haute disponibilité.
Pour plus d'informations, reportez-vous à Création de la base de données d'état de secours.