Eine Best Practices für Resilienz

In diesem Thema werden Best Practices beschrieben, mit denen der Betrieb fortgesetzt werden kann, falls eine einzelne virtuelle Maschine (VM) einer Enterprise-Ausprägungsinstanz von Oracle Blockchain Platform zur Wartung offline gesetzt wird oder unerwartet ausfällt.

Die folgenden Schritte gelten nur für Instanzen von Oracle Blockchain Platform basierend auf der Enterprise-Ausprägung (nicht der Standardausprägung). Darüber hinaus gilt diese Anleitung nur für die folgenden Deployment-Modelle:
  • Eine einzige Gründerorganisation
  • Ein Gründer mit einer oder mehreren teilnehmenden Organisationen
Da Instanzen von Oracle Blockchain Platform basierend auf der Standardausprägung alle Komponenten (Peers, Orderer und Plattformservices) auf einer einzelnen VM ausführen, ist die gesamte Instanz nicht verfügbar, wenn eine VM ausfällt oder zur Wartung gestoppt werden muss. Es gibt keine Isolation über Availability-Domains oder Faultdomains hinweg. Verwenden Sie keine Instanzen basierend auf der Standardausprägung für Produktionsumgebungen.

Verwenden Sie stattdessen Instanzen basierend auf der Enterprise-Ausprägung für Produktionsumgebungen. Diese Instanzen bieten eine unabhängige Skalierung von Hyperledger Fabric-Komponenten und Konfigurationen mit höherer Kapazität. Instanzen mit Unternehmensausprägung verteilen automatisch Peers, Orderer und Plattformkomponenten über Availability-Domains und Faultdomains hinweg, um eine Faultisolation auf Infrastrukturebene bereitzustellen. Um dieses Verhalten zu nutzen und eine hohe Verfügbarkeit sicherzustellen, verwenden Sie die in den folgenden Abschnitten beschriebenen Best Practices.

Bestätigungsrichtlinien

Verwenden Sie für ein Netzwerk mit einer einzelnen (Gründer-)Organisation Bestätigungs-Policys, mit denen jeder verfügbare Peer Transaktionen freigeben kann, wie OR('Founder.member') oder OutOf(1, 'Founder.member'). Stellen Sie mindestens zwei Kollegen für die Gründerorganisation bereit.

Für ein Netzwerk mit einem Gründer und einer Teilnehmerorganisation können Sie normalerweise die folgende Policy verwenden: OutOf(1, 'Founder.member', 'Participant1.member'). Für eine strengere Konfiguration können Sie OutOf(2, 'Founder.member', 'Participant1.member') nur verwenden, wenn Redundanz vorhanden ist. Vermeiden Sie strenge Policys wie AND('Founder.member', 'Participant1.member'), es sei denn, beide Organisationen verfügen über ausreichende Peerredundanz.

Weitere Informationen finden Sie unter Freigabe-Policy angeben.

Peer-Bereitstellung

Stellen Sie mindestens zwei Peers pro Organisation bereit. Oracle Blockchain Platform verteilt Peers automatisch über Availability-Domains und Faultdomains, um sicherzustellen, dass nach einem VM-Fehler mindestens ein Peer verfügbar bleibt.

Private Datenerfassung

Wenn Sie private Datensammlungen verwenden, setzen Sie den Wert Erforderliche Peers (requiredPeerCount) auf einen oder mehrere Werte, und setzen Sie den Wert Max. Peeranzahl (maxPeerCount) in der Definition der privaten Datensammlung auf zwei oder mehr Werte. Stellen Sie sicher, dass mindestens zwei Peers Mitglieder jeder privaten Datenerfassung sind und dass private Daten über mindestens zwei Peers hinweg festgeschrieben werden. Der Wert Erforderliche Peers ist die Mindestanzahl von Peers (mit Ausnahme des Endorsing-Peers), die die privaten Daten erfolgreich empfangen müssen, bevor das Transaktionsvorschlag als abgeschlossen betrachtet wird.

Konfigurieren Sie für organisationsübergreifende private Datenerfassungen, dass die erforderliche Peeranzahl größer als die Anzahl der Peers aus einer einzelnen Organisation ist, und stellen Sie eine Verteilung über mehrere Organisationen und VMs sicher.

Weitere Informationen finden Sie unter Private Datensammlungen hinzufügen.

Raft-Bestellservice

Verwenden Sie den standardmäßigen Raft-Bestellservice mit drei Knoten. Oracle Blockchain Platform verteilt Besteller auf Availability-Domains und Faultdomains, sodass der Bestellservice einen Ausfall eines einzelnen Knotens bewältigen kann.

Gleichgestellte Anker

Konfigurieren Sie in Netzwerken mit mehreren Organisationen mindestens einen Anker-Peer pro Organisation. Um die Resilienz zu verbessern, konfigurieren Sie mindestens zwei Anker-Peers pro Organisation. Anker-Peers werden nur benötigt, wenn mehrere Oracle Blockchain Platform-Organisationsinstanzen im Netzwerk vorhanden sind, da sie Klatsch-basierte Kommunikation und Peer Discovery über verschiedene Organisationen hinweg ermöglichen.

Weitere Informationen finden Sie unter Anker-Peer hinzufügen.

Chaincode-Deployment

Um die Kontinuität sicherzustellen, wenn ein Peer nicht verfügbar ist, installieren und genehmigen Sie Chaincode auf mindestens zwei Peers pro Organisation. Sie können diese Deployments auf Oracle Blockchain Platform-Instanzen in einem Netzwerk verteilen, wenn Ihre Datenschutzanforderungen dies zulassen.

Clientkonnektivität

Konfigurieren Sie Clientanwendungen so, dass sie niemals auf bestimmte Peers latch. Lassen Sie stattdessen zu, dass die zugrunde liegende Clientbibliothek mit der Peerauswahl umgehen kann.

Fallback-Statusdatenbank

Die Statusdatenbank wird auf jedem Peer für alle Channels gespeichert, mit denen der Peer verknüpft ist. Wenn eine VM ausfällt, ist die lokale Statusdatenbank auf diesem Peer erst dann verfügbar, wenn der Peer wiederhergestellt wurde. Oracle Blockchain Platform unterstützt ein hybrides Statusdatenbankmodell, bei dem eine externe Oracle Database als Fallback-(sekundäre) Statusdatenbank fungiert. Wenn die Fallback-Statusdatenbank aktiviert ist, werden Statusdaten außerhalb der Peer-VM in einer Datenbank persistiert, die bei Bedarf als primäre Statusdatenbank übernommen werden kann, was die Dauerhaftigkeit und das Recovery verbessert.

Gehen Sie folgendermaßen vor, um diese Funktion zur Verbesserung der Resilienz zu verwenden.
  • Fallback-Statusdatenbank für Produktions-Workloads oder kritische Workloads aktivieren
  • Stellen Sie Oracle Database unabhängig von den Peer-VMs bereit.
  • Konfigurieren Sie Oracle Database für High Availability.
Durch diese Schritte können Sie sicherstellen, dass Statusdaten nicht an den Lebenszyklus einer einzelnen VM gebunden sind. Die Fallback-Statusdatenbank arbeitet in Ergänzung zur Peerredundanz für Szenarios, in denen eine einzelne VM ausfällt.

Weitere Informationen finden Sie unter Fallback-Statusdatenbank erstellen.