Dieser Artikel ist ein Nachdruck des Medium-Artikels von TIS Co., Ltd. (genehmigt). Text-URL: https://medium.com/@TIS_BC_Prom/r3-corda%E3%83%8E%E3%83%BC%E3%83%89%E3%81%AE%E9%AB%98%E5% 8F% AF% E7% 94% A8% E6% 80% A7-ha-% E3% 81% A8% E3% 81% 9D% E3% 81% AE% E6% A7% 8B% E6% 88% 90% E6 % 96% B9% E6% B3% 95-34cb5dd409d1
Corda Enterprise unterstützt seit der Veröffentlichung von Version 3.2 offiziell die "Hot-Cold-Hochverfügbarkeitsbereitstellung" für Corda-Knoten. Welche Einstellungen sollten für diese "Hot-Cold-Hochverfügbarkeitsbereitstellung" vorgenommen werden, wie sollte sie sich verhalten und kann eine hohe Verfügbarkeit garantiert werden? Ich habe ungefähr bestätigt, also werde ich es vorstellen.
In diesem Artikel wird die AWS-Umgebung zum Konfigurieren der HA-Einstellungen für Corda-Knoten verwendet. Außerdem werden alle AWS-Instanzen in derselben VPC eingerichtet.
-PostgreSQL wird für die Datenbank des Corda-Knotens mit HA-Einstellungen verwendet. Die anderen Corda-Knoten verwenden die Standard-H2-DB.
-Jeder Knoten wird mit einer EC2-Instanz erstellt. Das Betriebssystem ist Ubuntu, 18.04 LT.
Befolgen Sie zum Einrichten der CorDapp-Entwicklungsumgebung die offizielle Corda-Dokumentation.
https://docs.corda.r3.com/getting-set-up.html
・ Corda offizielle Website, auf die ich verwiesen habe
-Die Datenbank des HA-Knotens (im Folgenden als Partei B bezeichnet) verwendet den AWS RDS-Dienst.
-AWS ELB (Classic Load Balancer) wird als Load Balancer für PartyB verwendet.
Cordas "Hot-Cold-Hochverfügbarkeitsbereitstellung" ist im Grunde die Idee des "HA-Clusters". Es wird in "Shared Disk Configuration" auf der R3-Website vorgestellt. Ich werde die Rolle des Load Balancers, EFS und RDS von AWS erläutern, die bei dieser Überprüfung verwendet werden.
EFS wird als freigegebenes Netzwerklaufwerk für P2P-Nachrichtenbrokerdateien verwendet. Daher kann auf P2P-Nachrichten zugegriffen werden, unabhängig davon, ob sie aktiv oder inaktiv sind. Wir verwenden dieses Netzlaufwerk auch, um festzustellen, welcher Knoten aktiv ist. Mit anderen Worten, der Mechanismus, den nur ein Knoten im HA-Cluster startet, wird mithilfe des Netzwerklaufwerks realisiert.
Abbildung 1 Übersicht über die HA-Einstellungen in diesem Artikel
Der Load Balancer wird verwendet, um eingehenden Datenverkehr (P2P, RPC und HTTP) zum aktiven Corda-Knoten umzuleiten, z. B. zum Hot Party B-Knoten in Abbildung 1. Im Folgenden finden Sie die Schritte zum Erstellen eines Load Balancers.
Klicken Sie auf die Schaltfläche Load Balancer erstellen, um den Load Balancer zu erstellen.
Vier. Die Werte für Load Balun-Unterstützung und Instanzport sollten mit den in der Datei PartyB node.conf festgelegten Werten für "p2pAddress" und "rpcSettings" übereinstimmen.
Fünf. Folgen Sie der offiziellen Website (https://docs.corda.r3.com/hot-cold-deployment.html), um [Sicherheitsgruppe] und [Gesundheitscheck] abzuschließen.
Notieren Sie sich den DNS-Namen des neu erstellten Load Balancers. Dies wird für spätere Einstellungen verwendet (Abschnitt F).
Da das Verfahren auf der offiziellen Website und in AWS (https://docs.aws.amazon.com/ja_jp/efs/latest/ug/getting-started.html) veröffentlicht wird, wird das detaillierte Verfahren weggelassen, jedoch das Folgende Ich werde die zu beachtenden Punkte erläutern.
EFS muss dasselbe Subnetz und dieselbe Sicherheitsgruppe wie der PartyB-Knoten verwenden.
Notieren Sie sich nach dem Erstellen des EFS das "Amazon EC2-Bereitstellungsverfahren (von Ihrer lokalen VPC)". Wir werden diese Schritte später ausführen, wenn wir dieses EFS auf zwei HA-Knoten (PartyB Hot / Cold) bereitstellen.
Informationen zum Erstellen einer PostgreSQL-Instanz
Erstellen Sie eine PostgreSQL-Instanz in AWS. (Der Einstellvorgang entfällt.) Hier einige Hinweise.
Laut der offiziellen Website von Corda wurde PostgreSQL 9.6 mit JDBC-Treiber 42.1.4 getestet. Bei dieser Überprüfung habe ich PostgreSQL 10 mit demselben Treiber verwendet, aber es funktionierte normal ohne Probleme. https://docs.corda.r3.com/releases/3.3/node-database.html?highlight=node%20database%20developer#postgresql
Passen Sie die Einstellungen für das Subnetz und die Sicherheitsgruppe der DB-Instanz an die Einstellungen für den Knoten LB und Party B an.
Notieren Sie sich den Endpunktnamen der neu erstellten DB-Instanz. Dies wird für die spätere Konfiguration verwendet (Abschnitt F).
Informationen zum Einrichten einer PostgreSQL-Instanz
Verwenden Sie ein DB-Verbindungsclient-Tool eines Drittanbieters wie pgAdmin4, um eine Verbindung zu der oben erstellten DB-Instanz herzustellen. Stellen Sie als Administrator eine Verbindung zur DB-Instanz her und erstellen Sie eine Datenbank.
Erstellen Sie einen Knotenbenutzer und ein Schema mit dem offiziellen Skript.
(https://docs.corda.r3.com/releases/3.3/node-database.html#postgresql)
CREATE USER "my_user" WITH LOGIN PASSWORD 'my_password';
CREATE SCHEMA "my_schema";
GRANT USAGE, CREATE ON SCHEMA "my_schema" TO "my_user";
GRANT SELECT, INSERT, UPDATE, DELETE, REFERENCES ON ALL tables IN SCHEMA "my_schema" TO "my_user";
ALTER DEFAULT privileges IN SCHEMA "my_schema" GRANT SELECT, INSERT, UPDATE, DELETE, REFERENCES ON tables TO "my_user";
GRANT USAGE, SELECT ON ALL sequences IN SCHEMA "my_schema" TO "my_user";
ALTER DEFAULT privileges IN SCHEMA "my_schema" GRANT USAGE, SELECT ON sequences TO "my_user";
ALTER ROLE "my_user" SET search_path = "my_schema";
Nach dem Ausführen des obigen Skripts wird das Schema in der erstellten Datenbank erstellt.
Die diesmal zur Überprüfung eingestellten Einstellungsinhalte werden beschrieben.
Fügen Sie der Datei build.gradle Informationen zu HA-Einstellungen hinzu.
Um einen Knoten (z. B. PartyB) für HA-Einstellungen zu konfigurieren, müssen Sie nur die relevanten Konfigurationsinformationen für diesen Knoten ändern. Das Folgende ist eine Beschreibung einschließlich Notizen.
build.gradle
…<Abkürzung>…
node {
name "O=PartyB,L=Tokyo,C=JP"
p2pAddress "internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008"
//Die obige Adresse ist der DNS-Name des in Abschnitt C erstellten Load Balancers.
//Andere Corda-Knoten sind PartyB (Hot) über den oben genannten Load Balancer/Kalt) Stellen Sie eine Verbindung zum Knoten her.
rpcSettings {
address("0.0.0.0:10009")
adminAddress("0.0.0.0:10049")
}
//RPC-Adresse 0.0.0.Zuweisen zu 0. Dies liegt daran, dass diese Adressen beim Start vom Knoten selbst verwendet werden und nicht von anderen Knoten aufgerufen werden müssen.
//Wie auf der offiziellen Website angegeben, wird möglicherweise die Fehlermeldung "Angeforderte Adresse kann nicht zugewiesen werden" angezeigt, wenn Sie die IP-Adresse des Frontcomputers festlegen.
extraConfig = [
jarDirs : ["/***/***/"],
//Treiber “postgresql-42.1.4.Bitte stellen Sie das Verzeichnis ein, in dem sich jar befindet.
"dataSourceProperties.dataSource.url": "jdbc:postgresql://ce4-pgsql.************.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2",
//DataSource oben.URL ist der DB-Endpunkt (erstellt in Abschnitt E)/PGSQL Server-Portnummer (Standard ist 5432)/Datenbankname (erstellt in Abschnitt E).
"dataSourceProperties.dataSourceClassName": "org.postgresql.ds.PGSimpleDataSource",
"dataSourceProperties.dataSource.user": "*****",
"dataSourceProperties.dataSource.password": "*****",
"database.transactionIsolationLevel": "READ_COMMITTED",
"database.schema": "my_schema",
"database.runMigration": "true"
//Um die erforderlichen Tabellen beim Start des Knotens erstellen zu können, Datenbank.runMigration Auf "true" setzen.
]
cordapps = [
"$project.group:cordapp-contracts-states:$project.version",
"$project.group:cordapp:$project.version"
]
rpcUsers = [[ user: "user1", "password": "test", "permissions": ["ALL"]]]
}
…<Abkürzung>…
Speichern Sie die geänderte Datei <build.gradle> oben und führen Sie "./gradlew deployNodes" im CorDapps-Verzeichnis aus, um mit dem Kompilieren von CorDapps zu beginnen.
Wenn CorDapps erfolgreich kompiliert wurde, wird eine Meldung ähnlich der folgenden angezeigt.
…<Abkürzung>…
node {
name "O=PartyB,L=Tokyo,C=JP"
p2pAddress "internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008"
//Die obige Adresse ist der DNS-Name des in Abschnitt C erstellten Load Balancers.
//Andere Corda-Knoten sind PartyB (Hot) über den oben genannten Load Balancer/Kalt) Stellen Sie eine Verbindung zum Knoten her.
rpcSettings {
address("0.0.0.0:10009")
adminAddress("0.0.0.0:10049")
}
//RPC-Adresse 0.0.0.Zuweisen zu 0. Dies liegt daran, dass diese Adressen beim Start vom Knoten selbst verwendet werden und nicht von anderen Knoten aufgerufen werden müssen.
//Wie auf der offiziellen Website angegeben, wird möglicherweise die Fehlermeldung "Angeforderte Adresse kann nicht zugewiesen werden" angezeigt, wenn Sie die IP-Adresse des Frontcomputers festlegen.
extraConfig = [
jarDirs : ["/***/***/"],
//Treiber “postgresql-42.1.4.Bitte stellen Sie das Verzeichnis ein, in dem sich jar befindet.
"dataSourceProperties.dataSource.url": "jdbc:postgresql://ce4-pgsql.************.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2",
//DataSource oben.URL ist der DB-Endpunkt (erstellt in Abschnitt E)/PGSQL Server-Portnummer (Standard ist 5432)/Datenbankname (erstellt in Abschnitt E).
"dataSourceProperties.dataSourceClassName": "org.postgresql.ds.PGSimpleDataSource",
"dataSourceProperties.dataSource.user": "*****",
"dataSourceProperties.dataSource.password": "*****",
"database.transactionIsolationLevel": "READ_COMMITTED",
"database.schema": "my_schema",
"database.runMigration": "true"
//Um die erforderlichen Tabellen beim Start des Knotens erstellen zu können, Datenbank.runMigration Auf "true" setzen.
]
cordapps = [
"$project.group:cordapp-contracts-states:$project.version",
"$project.group:cordapp:$project.version"
]
rpcUsers = [[ user: "user1", "password": "test", "permissions": ["ALL"]]]
}
…<Abkürzung>…
Die Verzeichnisse für alle Corda-Knoten, einschließlich PartyB, werden jetzt unter "build / node" erstellt. Die Datei PartyB node.conf sieht folgendermaßen aus:
ataSourceProperties {
dataSource {
password=*****
url="jdbc:postgresql://ce4-pgsql.************.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2"
user=*****
}
dataSourceClassName="org.postgresql.ds.PGSimpleDataSource"
}
database {
runMigration="true"
schema="my_schema"
transactionIsolationLevel="READ_COMMITTED"
}
devMode=true
jarDirs=[
"/***/***/"
]
myLegalName="O=PartyB,L=Osaka,C=JP"
p2pAddress="internal- PartyB-HA-LB -*********.ap-northeast-1.elb.amazonaws.com:10008"
rpcSettings {
address="0.0.0.0:10009"
adminAddress="0.0.0.0:10049"
}security {
authService {
dataSource {
type=INMEMORY
users=[
{
password=test
permissions=[
ALL
]
user=user1
}
]
}
}
}
Darüber hinaus enthält die Datenbank alle von Corda benötigten Tabellen.
Bitte beachten Sie, dass die anderen von CorDapps benötigten Tabellen noch nicht erstellt wurden. Dies wird später in Abschnitt I erörtert.
Kopieren Sie dann das Verzeichnis jedes Corda-Knotens auf den entsprechenden Server. .. In diesem Artikel kopieren wir es in die EC2-Instanz jedes Corda-Knotens. Kopieren Sie das Verzeichnis Party HA (HA Node) in die beiden EC2-Instanzen (HA-Hot (AZ1) und HA-Cold (AZ1)), die Sie in Schritt 4 von Abschnitt C zum Load Balancer hinzugefügt haben.
https://gist.github.com/luomin/263460bc930bc30ab719dd390394016c#file-logs-in-partyb-cold-node-txn-b
Melden Sie sich bei der EC2-Instanz für die beiden oben genannten Party Bs an. Nehmen Sie für beide Instanzen die folgenden Einstellungen vor.
mkdir artemis
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-*******.efs.ap-northeast-1.amazonaws.com:/ artemis
// Siehe den Hinweis in Sitzung D, um das Obige zu sehen. ..
e.g. chown ubuntu:ubuntu artemis
Wenn sie nicht identisch sind, wird beim Starten des PartyB-Knotens ein Fehler ähnlich dem folgenden angezeigt:
---------- Corda Enterprise Edition 4.0 (8dcaeef) -------------------
Tip: If you don't wish to use the shell it can be disabled with the --no-local-shell flag
Logs can be found in : /path to your cordapp directory/build/nodes/PartyB/logs
! ATTENTION: This node is running in development mode! This is not safe for production deployment.
Database connection url is : jdbc:postgresql://ce4-pgsql.************.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2
Advertised P2P messaging addresses : internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008
RPC connection address : 0.0.0.0:10009
RPC admin connection address : 0.0.0.0:10049
[ERROR] 03:25:07+0000 [main] internal.Node.start - Messaging service could not be started.
Shutting down ...
[ERROR] 03:25:07+0000 [main] internal.NodeStartupLogging.invoke - Exception during node startup [errorCode=b46fui, moreInformationAt=https://errors.corda.net/ENT/4.0/b46fui]
Melden Sie sich bei allen EC2-Instanzen an und greifen Sie auf das Corda-Knotenverzeichnis zu, das Sie dort kopiert haben.
Führen Sie "java -jar corda.jar" in diesem Verzeichnis aus, um den Corda-Knoten zu starten
Wenn Sie jedoch den HA-Knoten (PartyB) starten, wird möglicherweise eine Fehlermeldung angezeigt, die der folgenden ähnelt:
------------------ Corda Enterprise Edition 4.0 (8dcaeef) ---------------------------
Tip: You can issue SQL queries to the database from the Corda shell with the jdbc command
Logs can be found in : /path to PartyB folder/logs
! ATTENTION: This node is running in development mode! This is not safe for production deployment.
Database connection url is : jdbc:postgresql://ce4-pgsql.***********.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2
[ERROR] 04:24:40+0000 [main] internal.NodeStartupLogging.invoke - Could not create the DataSource: No migration defined for schema: poc.schemas.**Schema v1: Could not create the DataSource: No migration defined for schema: poc.schemas.**Schema v1 [errorCode=5k06pt, moreInformationAt=https://errors.corda.net/ENT/4.0/5k06pt]
Dies liegt daran, dass die für CorDapps erforderlichen Schemas / Tabellen nicht in PostgreSQL DB erstellt wurden, wie in Abschnitt G beschrieben.
Führen Sie den folgenden Befehl im Arbeitsverzeichnis von Abschnitt G (der Umgebung, in der Sie CorDapp erstellen) aus, um das erforderliche "Migrationsskript" zu erstellen.
java -jar tools-database-manager-4.0.jar - base-directory /full-path-to-your-cordapp/build/nodes/PartyB - create-migration-sql-for-cordapp
cd build/nodes/PartyB
jar cvf cordapps/migration.jar migration
cd ../../..
java -jar tools-database-manager-4.0.jar - base-directory /full-path-to-your-cordapp/build/nodes/PartyB - dry-run
java -jar tools-database-manager-4.0.jar - base-directory /full-path-to-your-cordapp/build/nodes/PartyB - execute-migration
Die offizielle Corda-Website enthält Anweisungen für diese Befehle. https://docs.corda.r3.com/database-management.html?highlight=node%20migration#adding-database-migration-scripts-retrospectively-to-an-existing-cordapp
Das Migrationsskript wird als JAR-Datei im CorDapps-Verzeichnis von PartyB erstellt.
Sie haben jetzt das erforderliche Schema für CorDapps in PostgreSQL DB erstellt. Beispielsweise wurde die in diesem Artikel verwendete Tabelle "qd_states" für CorDapp neu erstellt.
Die EC2-Instanz HA-Hot (AZ1) startet den PartyB-Knoten nun erfolgreich mit einer Konsolenmeldung ähnlich der folgenden: HA-Cold (AZ1) befindet sich im Startwartezustand.
ubuntu@ip-**.**.**.**$ java -jar corda.jar
*************************************************************************************************************************************
* All rights reserved. *
* This software is proprietary to and embodies the confidential technology of R3 LLC ("R3"). *
* Possession, use, duplication or dissemination of the software is authorized only pursuant to a valid written license from R3. *
* IF YOU DO NOT HAVE A VALID WRITTEN LICENSE WITH R3, DO NOT USE THIS SOFTWARE. *
*************************************************************************************************************************************
______ __ _____ _ _ _____ _____ ____ ____ ____ ___ ____ _____
/ ____/ _________/ /___ _ | ____| \ | |_ _| ____| _ \| _ \| _ \|_ _/ ___|| ____|
/ / __ / ___/ __ / __ `/ | _| | \| | | | | _| | |_) | |_) | |_) || |\___ \| _|
/ /___ /_/ / / / /_/ / /_/ / | |___| |\ | | | | |___| _ <| __/| _ < | | ___) | |___
\____/ /_/ \__,_/\__,_/ |_____|_| \_| |_| |_____|_| \_\_| |_| \_\___|____/|_____|
--- Corda Enterprise Edition 4.0 (8dcaeef) --------------------------------------------------
Tip: You can issue SQL queries to the database from the Corda shell with the jdbc command
Logs can be found in : /full-path-to-PartyB-folder/logs
! ATTENTION: This node is running in development mode! This is not safe for production deployment.
Database connection url is : jdbc:postgresql://ce4-pgsql.********.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2
Advertised P2P messaging addresses : internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008
RPC connection address : 0.0.0.0:10009
RPC admin connection address : 0.0.0.0:10049
Loaded 3 CorDapp(s) : Contract CorDapp: ***
Node for "PartyB" started up and registered in 16.17 sec
Welcome to the Corda interactive shell.
Useful commands include 'help' to see what is available, and 'bye' to shut down the node.
Thu May 23 05:26:59 UTC 2019>>>
Alle Codierknoten werden jetzt erfolgreich auf der EC2-Instanz gestartet, wie in Abbildung 1 dargestellt.
Wenn Sie beispielsweise eine Transaktion (txn-a) zwischen PartyA und PartyB ausgeben, wird txn-a erfolgreich abgeschlossen. Wenn Sie die Protokolldatei des PartyA-Knotens überprüfen, wird aufgezeichnet, dass PartyA tatsächlich mit dem Load Balancer verbunden und mit PartyB verbunden ist:
[INFO ] 2019-05-23T05:48:44,588Z [Messaging executor] messaging.P2PMessagingClient.createQueueIfAbsent - Create fresh queue internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr bound on same address {}
[INFO ] 2019-05-23T05:48:44,629Z [Thread-28 (ActiveMQ-client-global-threads)] bridging.BridgeControlListener.processControlMessage - Received bridge control message Create(nodeIdentity=O=PartyA, L=Osaka, C=JP, bridgeInfo=BridgeEntry(queueName=internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr, targets=[internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008], legalNames=[O=PartyB, L=Osaka, C=JP], serviceAddress=false)) {
// note: above msg shows PartyA was trying to connect the LoadBalancer. "targets=[internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008"
[INFO ] 2019-05-23T05:48:44,629Z [Thread-28 (ActiveMQ-client-global-threads)] bridging.LoopbackBridgeManager.deployBridge - Deploying AMQP bridge for internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr, source O=PartyA, L=Osaka, C=JP {}
[INFO ] 2019-05-23T05:48:44,648Z [Thread-28 (ActiveMQ-client-global-threads)] bridging.AMQPBridgeManager$AMQPBridge.invoke - Create new AMQP bridge {legalNames=O=PartyB, L=Osaka, C=JP, maxMessageSize=10485760, queueName=internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr, source=O=PartyA, L=Osaka, C=JP, targets=internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008}
[INFO ] 2019-05-23T05:48:44,649Z [Thread-28 (ActiveMQ-client-global-threads)] netty.AMQPClient.start - connect to: internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008 {}
[INFO ] 2019-05-23T05:48:44,784Z [nioEventLoopGroup-2-1] netty.AMQPClient.operationComplete - Connected to internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008 {}
[INFO ] 2019-05-23T05:48:44,788Z [nioEventLoopGroup-2-1] netty.AMQPChannelHandler.invoke - New client connection 790466bd from internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008 to /26.132.139.158:37634 {allowedRemoteLegalNames=O=PartyB, L=Osaka, C=JP, localCert=null, remoteAddress=internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008, remoteCert=null, serverMode=false}
[INFO ] 2019-05-23T05:48:44,846Z [nioEventLoopGroup-2-1] netty.LoggingTrustManagerWrapper.checkServerTrusted - Check Server Certpath:^M
C=JP,L=Osaka,O=PartyB[E341A0565CDBFF8699CBA8CB377382C0513CB0EA] issued by C=JP,L=Osaka,O=PartyB[1D6C7F86F4F99AED0CE281FE996A0C70DC5EFBB1]^M
C=JP,L=Osaka,O=PartyB[1D6C7F86F4F99AED0CE281FE996A0C70DC5EFBB1] issued by C=US,L=New York,OU=Corda,O=R3 HoldCo LLC,CN=Corda Doorman CA[EBEE2E30152940AE19981ED86FE37D7F07A2C213]^M
C=US,L=New York,OU=Corda,O=R3 HoldCo LLC,CN=Corda Doorman CA[EBEE2E30152940AE19981ED86FE37D7F07A2C213] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773]^M
CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[null] {}
[INFO ] 2019-05-23T05:48:44,891Z [nioEventLoopGroup-2-1] netty.AMQPChannelHandler.invoke - Handshake completed with subject: O=PartyB, L=Osaka, C=JP, requested server name: e8c5bf64fbba23612e26a3302a65c60a.corda.net. {allowedRemoteLegalNames=O=PartyB, L=Osaka, C=JP, localCert=O=PartyA, L=Osaka, C=JP, remoteAddress=internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008, remoteCert=O=PartyB, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T05:48:45,015Z [nioEventLoopGroup-2-1] bridging.AMQPBridgeManager$AMQPBridge.invoke - Bridge Connected {legalNames=O=PartyB, L=Osaka, C=JP, maxMessageSize=10485760, queueName=internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr, source=O=PartyA, L=Osaka, C=JP, targets=internal- PartyB-HA-LB-********.ap-northeast-1.elb.amazonaws.com:10008}
Logs in PartyA (txn-a)
Sie können auch sehen, dass der aktive Knoten von PartyB den obigen txn-a mit PartyA verarbeitet.
[INFO ] 2019-05-23T05:37:25,681Z [Node thread-1] internal.Node.registerJolokiaReporter - Registering Jolokia JMX reporter: {}
//In PartyBs Cold Node, txn-Es gibt keine Protokollinformationen zu a
logs in PartyB cold (txn-a)
[INFO ] 2019-05-23T05:26:59,167Z [Node thread-1] internal.Node.registerJolokiaReporter - Registering Jolokia JMX reporter: {}
//Danach txn-Es ist ein Protokoll von a.
[INFO ] 2019-05-23T05:49:18,883Z [Messaging executor] messaging.P2PMessagingClient.createQueueIfAbsent - Create fresh queue internal.peers.DLANwREshETUbbSsJhFT4PHMHLqnSvHBzVrzxTd6faYGeF bound on same address {}
[INFO ] 2019-05-23T05:49:18,978Z [Thread-8 (ActiveMQ-client-global-threads)] bridging.BridgeControlListener.processControlMessage - Received bridge control message Create(nodeIdentity=O=PartyB, L=Osaka, C=JP, bridgeInfo=BridgeEntry(queueName=internal.peers.DLANwREshETUbbSsJhFT4PHMHLqnSvHBzVrzxTd6faYGeF, targets=[26.132.139.158:10005], legalNames=[O=PartyA, L=Osaka, C=JP], serviceAddress=false)) {}
[INFO ] 2019-05-23T05:49:18,979Z [Thread-8 (ActiveMQ-client-global-threads)] bridging.LoopbackBridgeManager.deployBridge - Deploying AMQP bridge for internal.peers.DLANwREshETUbbSsJhFT4PHMHLqnSvHBzVrzxTd6faYGeF, source O=PartyB, L=Osaka, C=JP {}
[INFO ] 2019-05-23T05:49:18,997Z [Thread-8 (ActiveMQ-client-global-threads)] bridging.AMQPBridgeManager$AMQPBridge.invoke - Create new AMQP bridge {legalNames=O=PartyA, L=Osaka, C=JP, maxMessageSize=10485760, queueName=internal.peers.DLANwREshETUbbSsJhFT4PHMHLqnSvHBzVrzxTd6faYGeF, source=O=PartyB, L=Osaka, C=JP, targets=26.132.139.158:10005}
[INFO ] 2019-05-23T05:49:18,998Z [Thread-8 (ActiveMQ-client-global-threads)] netty.AMQPClient.start - connect to: 26.132.139.158:10005 {}
[INFO ] 2019-05-23T05:49:19,124Z [nioEventLoopGroup-2-1] netty.AMQPClient.operationComplete - Connected to 26.132.139.158:10005 {}
[INFO ] 2019-05-23T05:49:19,149Z [nioEventLoopGroup-2-1] netty.AMQPChannelHandler.invoke - New client connection 16364379 from /26.132.139.158:10005 to /26.132.142.60:36896 {allowedRemoteLegalNames=O=PartyA, L=Osaka, C=JP, localCert=null, remoteAddress=/26.132.139.158:10005, remoteCert=null, serverMode=false}
[INFO ] 2019-05-23T05:49:19,258Z [nioEventLoopGroup-2-1] netty.LoggingTrustManagerWrapper.checkServerTrusted - Check Server Certpath:^M
C=JP,L=Osaka,O=PartyA[A5B65A4EF961EB9963C217598BDD2B3BAFD81263] issued by C=JP,L=Osaka,O=PartyA[8F7435C49DD49B99DB3D5083E40D8FEE34A62DDB]^M
C=JP,L=Osaka,O=PartyA[8F7435C49DD49B99DB3D5083E40D8FEE34A62DDB] issued by C=US,L=New York,OU=Corda,O=R3 HoldCo LLC,CN=Corda Doorman CA[EBEE2E30152940AE19981ED86FE37D7F07A2C213]^M
C=US,L=New York,OU=Corda,O=R3 HoldCo LLC,CN=Corda Doorman CA[EBEE2E30152940AE19981ED86FE37D7F07A2C213] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773]^M
CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[null] {}
[INFO ] 2019-05-23T05:49:19,366Z [nioEventLoopGroup-2-1] netty.AMQPChannelHandler.invoke - Handshake completed with subject: O=PartyA, L=Osaka, C=JP, requested server name: 26a6b0b27deba4660c3598ce3f39c668.corda.net. {allowedRemoteLegalNames=O=PartyA, L=Osaka, C=JP, localCert=O=PartyB, L=Osaka, C=JP, remoteAddress=/26.132.139.158:10005, remoteCert=O=PartyA, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T05:49:19,461Z [nioEventLoopGroup-2-1] bridging.AMQPBridgeManager$AMQPBridge.invoke - Bridge Connected {legalNames=O=PartyA, L=Osaka, C=JP, maxMessageSize=10485760, queueName=internal.peers.DLANwREshETUbbSsJhFT4PHMHLqnSvHBzVrzxTd6faYGeF, source=O=PartyB, L=Osaka, C=JP, targets=26.132.139.158:10005}
[INFO ] 2019-05-23T05:49:19,515Z [nioEventLoopGroup-2-1] engine.ConnectionStateMachine.invoke - Connection local open org.apache.qpid.proton.engine.impl.ConnectionImpl@4a5e5c39 {localLegalName=O=PartyB, L=Osaka, C=JP, remoteLegalName=O=PartyA, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T05:49:19,740Z [flow-worker] corda.flow.call - Received transaction acknowledgement request from party O=PartyA, L=Osaka, C=JP. {fiber-id=10000001, flow-id=1087877d-3892-4501-9b72-c714664c71b5, invocation_id=96c77912-6cea-4614-aced-8bba36aa5a34, invocation_timestamp=2019-05-23T05:49:18.397Z, origin=O=PartyA, L=Osaka, C=JP, session_id=96c77912-6cea-4614-aced-8bba36aa5a34, session_timestamp=2019-05-23T05:49:18.397Z, thread-id=268, tx_id=E4DA424F4AE1C5ABC22E2104E2481C2C811A54F61002154F3A1EFF80166726E9}
[INFO ] 2019-05-23T05:49:19,925Z [flow-worker] corda.flow.call - Transaction dependencies resolution completed. {fiber-id=10000001, flow-id=1087877d-3892-4501-9b72-c714664c71b5, invocation_id=96c77912-6cea-4614-aced-8bba36aa5a34, invocation_timestamp=2019-05-23T05:49:18.397Z, origin=O=PartyA, L=Osaka, C=JP, session_id=96c77912-6cea-4614-aced-8bba36aa5a34, session_timestamp=2019-05-23T05:49:18.397Z, thread-id=264, tx_id=E4DA424F4AE1C5ABC22E2104E2481C2C811A54F61002154F3A1EFF80166726E9}
[INFO ] 2019-05-23T05:49:23,419Z [flow-worker] corda.flow.call - Received transaction acknowledgement request from party O=PartyA, L=Osaka, C=JP. {fiber-id=10000001, flow-id=1087877d-3892-4501-9b72-c714664c71b5, invocation_id=96c77912-6cea-4614-aced-8bba36aa5a34, invocation_timestamp=2019-05-23T05:49:18.397Z, origin=O=PartyA, L=Osaka, C=JP, session_id=96c77912-6cea-4614-aced-8bba36aa5a34, session_timestamp=2019-05-23T05:49:18.397Z, thread-id=268, tx_id=E4DA424F4AE1C5ABC22E2104E2481C2C811A54F61002154F3A1EFF80166726E9}
// note: the msg in line 20 shows it was this PartyB (hot) node process the txn-a with PartyA
logs in PartyB hot (txn-a)
Stoppen Sie dann den Hot Node von PartyB und geben Sie eine zweite Transaktion aus (txn-b).
Sie können bestätigen, dass TXN-B auch normal abgeschlossen werden kann.
Übrigens, wenn Sie das PartyA-Protokoll überprüfen, können Sie feststellen, dass PartyA sofort nach dem Stoppen des aktiven Knotens von PartyB feststellt, dass PartyB getrennt wurde, und erneut eine Verbindung zum Load Balancer von PartyB herstellt.
[INFO ] 2019-05-23T05:48:50,765Z [nioEventLoopGroup-2-3] engine.ConnectionStateMachine.invoke - Connection local open org.apache.qpid.proton.engine.impl.ConnectionImpl@7f99bfe6 {localLegalName=O=PartyA, L=Osaka, C=JP, remoteLegalName=O=Regulator, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T07:15:10,415Z [nioEventLoopGroup-2-1] netty.AMQPClient.operationComplete - Disconnected from internal- PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008 {}
[INFO ] 2019-05-23T07:15:10,416Z [nioEventLoopGroup-2-1] netty.AMQPChannelHandler.invoke - Closed client connection 790466bd from internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008 to /26.132.139.158:37634 {allowedRemoteLegalNames=O=PartyB, L=Osaka, C=JP, localCert=O=PartyA, L=Osaka, C=JP, remoteAddress=internal-PartyB-HA-LB -*********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008, remoteCert=O=PartyB, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T07:15:10,417Z [nioEventLoopGroup-2-1] bridging.AMQPBridgeManager$AMQPBridge.invoke - Bridge Disconnected {legalNames=O=PartyB, L=Osaka, C=JP, maxMessageSize=10485760, queueName=internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr, source=O=PartyA, L=Osaka, C=JP, targets=internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008}
[INFO ] 2019-05-23T07:15:10,422Z [nioEventLoopGroup-2-1] engine.ConnectionStateMachine.invoke - Connection local close org.apache.qpid.proton.engine.impl.ConnectionImpl@1d3c4dab {localLegalName=O=PartyA, L=Osaka, C=JP, remoteLegalName=O=PartyB, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T07:15:10,424Z [nioEventLoopGroup-2-1] engine.ConnectionStateMachine.invoke - Transport Error TransportImpl [_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionImpl@1d3c4dab, org.apache.qpid.proton.engine.impl.TransportImpl@51b2ec6f] {localLegalName=O=PartyA, L=Osaka, C=JP, remoteLegalName=O=PartyB, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T07:15:10,424Z [nioEventLoopGroup-2-1] engine.ConnectionStateMachine.invoke - Error: connection aborted {localLegalName=O=PartyA, L=Osaka, C=JP, remoteLegalName=O=PartyB, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T07:15:11,416Z [nioEventLoopGroup-2-1] netty.AMQPClient.nextTarget - Retry connect to internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008 {}
[INFO ] 2019-05-23T07:15:11,431Z [nioEventLoopGroup-2-2] netty.AMQPClient.operationComplete - Connected to internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008 {}
[INFO ] 2019-05-23T07:15:11,432Z [nioEventLoopGroup-2-2] netty.AMQPChannelHandler.invoke - New client connection 2fab52c6 from internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008 to /26.132.139.158:37842 {allowedRemoteLegalNames=O=PartyB, L=Osaka, C=JP, localCert=null, remoteAddress=internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008, remoteCert=null, serverMode=false}
[INFO ] 2019-05-23T07:15:11,450Z [nioEventLoopGroup-2-2] netty.LoggingTrustManagerWrapper.checkServerTrusted - Check Server Certpath:^M
C=JP,L=Osaka,O=PartyB[E341A0565CDBFF8699CBA8CB377382C0513CB0EA] issued by C=JP,L=Osaka,O=PartyB[1D6C7F86F4F99AED0CE281FE996A0C70DC5EFBB1]^M
C=JP,L=Osaka,O=PartyB[1D6C7F86F4F99AED0CE281FE996A0C70DC5EFBB1] issued by C=US,L=New York,OU=Corda,O=R3 HoldCo LLC,CN=Corda Doorman CA[EBEE2E30152940AE19981ED86FE37D7F07A2C213]^M
C=US,L=New York,OU=Corda,O=R3 HoldCo LLC,CN=Corda Doorman CA[EBEE2E30152940AE19981ED86FE37D7F07A2C213] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773]^M
CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[7CAEA9DFB948012B13890B9AE645851C39170773] issued by CN=Corda Node Root CA,O=R3,OU=corda,L=London,C=UK[null] {}
[INFO ] 2019-05-23T07:15:11,479Z [nioEventLoopGroup-2-2] netty.AMQPChannelHandler.invoke - Handshake completed with subject: O=PartyB, L=Osaka, C=JP, requested server name: e8c5bf64fbba23612e26a3302a65c60a.corda.net. {allowedRemoteLegalNames=O=PartyB, L=Osaka, C=JP, localCert=O=PartyA, L=Osaka, C=JP, remoteAddress=internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com/26.132.138.97:10008, remoteCert=O=PartyB, L=Osaka, C=JP, serverMode=false}
[INFO ] 2019-05-23T07:15:11,481Z [nioEventLoopGroup-2-2] bridging.AMQPBridgeManager$AMQPBridge.invoke - Bridge Connected {legalNames=O=PartyB, L=Osaka, C=JP, maxMessageSize=10485760, queueName=internal.peers.DL33z2w7VP2FYTRrowmhC54mZVZQjtHhYxN2PzWL5hLovr, source=O=PartyA, L=Osaka, C=JP, targets=internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008}
[INFO ] 2019-05-23T07:15:11,484Z [nioEventLoopGroup-2-2] engine.ConnectionStateMachine.invoke - Connection local open org.apache.qpid.proton.engine.impl.ConnectionImpl@6455ea8d {localLegalName=O=PartyA, L=Osaka, C=JP, remoteLegalName=O=PartyB, L=Osaka, C=JP, serverMode=false}
//note: the msg in line 2 and line 8 show the PartyA detected the disconnection of PartyB(hot) and retry to connect to Loadbalancer.
Unten ist das Party A Txn-b Log. Dies zeigt an, dass PartyA die PartyB-Signatur (kalt) erfolgreich erhalten hat.
[INFO ] 2019-05-23T07:15:22,234Z [pool-8-thread-3] shell.StartShellCommand.main - Executing command "our txn-b commands here", {}
[INFO ] 2019-05-23T07:15:28,650Z [flow-worker] corda.flow.call - Sending transaction to notary: O=Notary, L=Osaka, C=JP. {actor_id=internalShell, actor_owning_identity=O=PartyA, L=Osaka, C=JP, actor_store_id=NODE_CONFIG, fiber-id=10000002, flow-id=b6aa33d8-307a-4338-b8bc-9ce8e3cf1962, invocation_id=2a2f2483-1a24-4702-8d0f-9f02072f27ab, invocation_timestamp=2019-05-23T07:15:22.263Z, origin=internalShell, session_id=e4fe6f15-d925-42e5-8510-30d00af8a86f, session_timestamp=2019-05-23T04:28:05.971Z, thread-id=903, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
…
[INFO ] 2019-05-23T07:15:30,639Z [flow-worker] corda.flow.call - Notary responded. {actor_id=internalShell, actor_owning_identity=O=PartyA, L=Osaka, C=JP, actor_store_id=NODE_CONFIG, fiber-id=10000002, flow-id=b6aa33d8-307a-4338-b8bc-9ce8e3cf1962, invocation_id=2a2f2483-1a24-4702-8d0f-9f02072f27ab, invocation_timestamp=2019-05-23T07:15:22.263Z, origin=internalShell, session_id=e4fe6f15-d925-42e5-8510-30d00af8a86f, session_timestamp=2019-05-23T04:28:05.971Z, thread-id=903, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:30,649Z [flow-worker] corda.flow.notariseAndRecord - Recording transaction locally. {actor_id=internalShell, actor_owning_identity=O=PartyA, L=Osaka, C=JP, actor_store_id=NODE_CONFIG, fiber-id=10000002, flow-id=b6aa33d8-307a-4338-b8bc-9ce8e3cf1962, invocation_id=2a2f2483-1a24-4702-8d0f-9f02072f27ab, invocation_timestamp=2019-05-23T07:15:22.263Z, origin=internalShell, session_id=e4fe6f15-d925-42e5-8510-30d00af8a86f, session_timestamp=2019-05-23T04:28:05.971Z, thread-id=903, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:30,708Z [flow-worker] corda.flow.notariseAndRecord - Recorded transaction locally successfully. {actor_id=internalShell, actor_owning_identity=O=PartyA, L=Osaka, C=JP, actor_store_id=NODE_CONFIG, fiber-id=10000002, flow-id=b6aa33d8-307a-4338-b8bc-9ce8e3cf1962, invocation_id=2a2f2483-1a24-4702-8d0f-9f02072f27ab, invocation_timestamp=2019-05-23T07:15:22.263Z, origin=internalShell, session_id=e4fe6f15-d925-42e5-8510-30d00af8a86f, session_timestamp=2019-05-23T04:28:05.971Z, thread-id=903, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:30,847Z [flow-worker] corda.flow.call - Party O=PartyB, L=Osaka, C=JP received the transaction. {actor_id=internalShell, actor_owning_identity=O=PartyA, L=Osaka, C=JP, actor_store_id=NODE_CONFIG, fiber-id=10000002, flow-id=b6aa33d8-307a-4338-b8bc-9ce8e3cf1962, invocation_id=2a2f2483-1a24-4702-8d0f-9f02072f27ab, invocation_timestamp=2019-05-23T07:15:22.263Z, origin=internalShell, session_id=e4fe6f15-d925-42e5-8510-30d00af8a86f, session_timestamp=2019-05-23T04:28:05.971Z, thread-id=912, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:30,847Z [flow-worker] corda.flow.call - All parties received the transaction successfully. {actor_id=internalShell, actor_owning_identity=O=PartyA, L=Osaka, C=JP, actor_store_id=NODE_CONFIG, fiber-id=10000002, flow-id=b6aa33d8-307a-4338-b8bc-9ce8e3cf1962, invocation_id=2a2f2483-1a24-4702-8d0f-9f02072f27ab, invocation_timestamp=2019-05-23T07:15:22.263Z, origin=internalShell, session_id=e4fe6f15-d925-42e5-8510-30d00af8a86f, session_timestamp=2019-05-23T04:28:05.971Z, thread-id=912, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
// note: the tx_id and msg in line 2 and 7 show that PartyA processed txn-b with PartyB
Unten finden Sie das Txn-b-Protokoll für Party B Cold Node. Dies zeigt an, dass PartyB (Cold) txn-b von PartyA empfangen und normal verarbeitet hat.
[INFO ] 2019-05-23T07:15:39,557Z [flow-worker] corda.flow.call - Transaction dependencies resolution completed. {fiber-id=10000001, flow-id=7ee8d76d-25f1-439a-9f43-45cffc8c10e1, invocation_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, invocation_timestamp=2019-05-23T07:15:38.233Z, origin=O=PartyA, L=Osaka, C=JP, session_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, session_timestamp=2019-05-23T07:15:38.233Z, thread-id=653, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:46,418Z [flow-worker] corda.flow.call - Received transaction acknowledgement request from party O=PartyA, L=Osaka, C=JP. {fiber-id=10000001, flow-id=7ee8d76d-25f1-439a-9f43-45cffc8c10e1, invocation_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, invocation_timestamp=2019-05-23T07:15:38.233Z, origin=O=PartyA, L=Osaka, C=JP, session_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, session_timestamp=2019-05-23T07:15:38.233Z, thread-id=658, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:46,459Z [flow-worker] corda.flow.call - Transaction dependencies resolution completed. {fiber-id=10000001, flow-id=7ee8d76d-25f1-439a-9f43-45cffc8c10e1, invocation_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, invocation_timestamp=2019-05-23T07:15:38.233Z, origin=O=PartyA, L=Osaka, C=JP, session_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, session_timestamp=2019-05-23T07:15:38.233Z, thread-id=661, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:46,496Z [flow-worker] corda.flow.call - Successfully received fully signed tx. Sending it to the vault for processing. {fiber-id=10000001, flow-id=7ee8d76d-25f1-439a-9f43-45cffc8c10e1, invocation_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, invocation_timestamp=2019-05-23T07:15:38.233Z, origin=O=PartyA, L=Osaka, C=JP, session_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, session_timestamp=2019-05-23T07:15:38.233Z, thread-id=661, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
[INFO ] 2019-05-23T07:15:46,626Z [flow-worker] corda.flow.call - Successfully recorded received transaction locally. {fiber-id=10000001, flow-id=7ee8d76d-25f1-439a-9f43-45cffc8c10e1, invocation_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, invocation_timestamp=2019-05-23T07:15:38.233Z, origin=O=PartyA, L=Osaka, C=JP, session_id=86bf5cb8-4442-4de4-93ef-075e6eba0877, session_timestamp=2019-05-23T07:15:38.233Z, thread-id=661, tx_id=DC1B4FBE9E052302EFDB733086C651C7615EDFFE6D37BD23450E45D9BB530D16}
// note: the tx_id and msg in line 1 and 5 show that this PartyB (cold) node processed txn-b with the PartyA
Wenn PartyB (heiß), das gestoppt wurde, neu gestartet wird und PartyB (kalt) im aktiven Zustand ist, wird der Corda-Prozess nicht gestartet und befindet sich in einem Wartezustand. Wenn die dritte Transaktion (txn-c) ausgegeben wird, wird txn-c daher von PartyB normal verarbeitet (kalt).
Selbst wenn ein Fehler im aktiven Knoten auftritt, wird der inaktive Knoten automatisch gestartet und während des Startvorgangs eine Weile gewartet. Da Transaktionen jedoch ohne Unterbrechung verarbeitet werden können, glauben wir, dass eine hohe Verfügbarkeit garantiert werden kann. Dies ist jedoch eine Hochverfügbarkeit nur für Knoten. Aus systemweiter Sicht sind Knoten, Load Balancer, gemeinsam genutzte Netzwerklaufwerke und Datenbanken die Ressourcen, die ein Corda-Knoten benötigt. Wenn einer von ihnen ausfällt, fungiert er nicht als Corda-Knoten. Eine hohe Verfügbarkeit des gesamten Systems kann nur garantiert werden, wenn eine HA-Cluster-Konfiguration für alle erforderlichen Ressourcen erstellt wurde.
In diesem Artikel wurden die Schritte und Vorsichtsmaßnahmen beschrieben, die zum Erstellen eines HA Corda-Knotens in einer AWS-Umgebung erforderlich sind.
Die neueste Corda Enterprise-Version (CE4.0) bietet einen alternativen Ansatz zur Konfiguration von HA-Knoten ohne Load Balancer. Im nächsten Artikel werde ich veröffentlichen, wie die Funktion eingestellt wird.
Hinweis: TIS Blockchain Promotion Office (Ra)
Thanks to Kiyotaka Yamasaki.
Dieser Artikel ist ein Nachdruck des Medium-Artikels von TIS Co., Ltd. (genehmigt). Text-URL: https://medium.com/@TIS_BC_Prom/r3-corda%E3%83%8E%E3%83%BC%E3%83%89%E3%81%AE%E9%AB%98%E5% 8F% AF% E7% 94% A8% E6% 80% A7-ha-% E3% 81% A8% E3% 81% 9D% E3% 81% AE% E6% A7% 8B% E6% 88% 90% E6 % 96% B9% E6% B3% 95-34cb5dd409d1
Anfragen zu diesem Artikel: SBI R3 Japan [email protected]
Recommended Posts