Cet article est une réimpression de l'article Medium de TIS Co., Ltd. (approuvé). URL du corps: 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 prend officiellement en charge le «déploiement haute disponibilité chaud-froid» pour les nœuds Corda depuis la sortie de la version 3.2. Quels types de paramètres doivent être définis pour ce "déploiement haute disponibilité chaud-froid", quel type de comportement doit-il se comporter et la haute disponibilité peut-elle être garantie? J'ai confirmé sur, donc je vais le présenter.

A. Introduction

Cet article utilise l'environnement AWS pour configurer les paramètres HA des nœuds Corda. De plus, toutes les instances AWS sont configurées dans le même VPC.

-PostgreSQL est utilisé pour la base de données du nœud Corda avec les paramètres HA. Les autres nœuds Corda utilisent la DB H2 par défaut.

-Chaque nœud est construit à l'aide d'une instance EC2. Le système d'exploitation est Ubuntu, 18.04 LT.

-Pour configurer l'environnement de développement CorDapp, suivez la documentation officielle de Corda.

https://docs.corda.r3.com/getting-set-up.html

・ Site officiel de Corda auquel j'ai fait référence

https://docs.corda.r3.com/releases/3.3/hot-cold-deployment.html

B. Image globale des paramètres HA dans cet article

-Le nœud Corda se compose de 4 instances EC2.

-La base de données du nœud HA (ci-après dénommée partie B) utilise le service AWS RDS.

-Le service Artemis de la partie B utilise le service EFS d'AWS (en tant que lecteur réseau partagé).

-AWS ELB (Classic Load Balancer) est utilisé comme équilibreur de charge requis pour PartyB.

Le «déploiement haute disponibilité chaud-froid» de Corda est essentiellement l'idée de «clustering HA». Il est présenté dans «Shared Disk Configuration» sur le site Web de R3. J'expliquerai le rôle de l'équilibreur de charge, d'EFS et de RDS d'AWS utilisé dans cette vérification.

1. L'équilibreur de charge surveille l'état de l'instance PartyB et achemine automatiquement le trafic des autres nœuds Party vers le nœud PartyB actif. Notez que la fonction Corda n'autorise qu'un seul nœud du cluster HA à démarrer, et même si vous essayez de démarrer le second, il sera dans un état d'attente. Dans cet état d'attente, il démarrera automatiquement lorsque la première unité deviendra inactive. L'adresse IP de l'équilibreur de charge (adresse représentative) sera annoncée aux autres réseaux Corda en tant qu'adresse P2P PartyB. Pour ce faire, définissez l'adresse IP de l'équilibreur de charge comme adresse P2P du nœud dans le fichier de configuration (build.gradle). Ceci est décrit dans la section F.
EFS est utilisé comme lecteur réseau partagé pour les fichiers du courtier de messages P2P. Par conséquent, les messages P2P sont accessibles indépendamment du fait qu'ils soient actifs ou inactifs. Nous utilisons également ce lecteur réseau pour voir quel nœud est actif. En d'autres termes, le mécanisme de démarrage d'un seul nœud du cluster HA est réalisé à l'aide du lecteur réseau.
1. RDS est utilisé comme DB partagé pour les nœuds HA car le même DB doit être référencé indépendamment du fait qu'il soit actif ou inactif.

Figure 1 Vue d'ensemble des paramètres HA dans cet article

C. Paramètres de l'équilibreur de route

L'équilibreur de charge est utilisé pour rediriger le trafic entrant (P2P, RPC et HTTP) vers le nœud Corda actif, par exemple le nœud Hot Party B de la figure 1. Vous trouverez ci-dessous les étapes pour créer un équilibreur de charge.

1. Visitez la page de la console Load Balancer sur AWS

Cliquez sur le bouton Créer un équilibreur de charge pour commencer à créer l'équilibreur de charge.

Sélectionnez Classic Load Balancer pour terminer la configuration.

1. Dans l'environnement de test de cet article, tous les nœuds Corda sont dans le même VPC, donc le type d'équilibreur de charge de cet environnement est «Créer un équilibreur de charge interne» au lieu de l'équilibreur de charge «externe» décrit sur le site officiel. Vous devez vérifier.

Quatre. La prise en charge de l'équilibrage de charge et les valeurs de port d'instance doivent être les mêmes que les valeurs «p2pAddress» et «rpcSettings» définies dans le fichier PartyB node.conf.

Cinq. Suivez le site Web officiel (https://docs.corda.r3.com/hot-cold-deployment.html) pour terminer [Security Group] et [Health Check].

Ajoutez deux instances EC2 (chaude / froide) de PartyB à l'équilibreur de charge. Exemple:

1. Lorsque vous avez terminé l'ensemble du processus, un nouvel équilibreur de charge est créé.

Notez le nom DNS de l'équilibreur de charge nouvellement créé. Ceci sera utilisé pour les réglages ultérieurs (section F).

D. Créez un EFS (lecteur réseau partagé pour les fichiers du courtier de messages P2P).

Étant donné que la procédure est publiée sur le site Web officiel et sur AWS (https://docs.aws.amazon.com/ja_jp/efs/latest/ug/getting-started.html), la procédure détaillée est omise, mais ce qui suit Je vais expliquer les points à noter.

EFS doit utiliser le même sous-réseau et le même groupe de sécurité que le nœud PartyB.
Une fois l'EFS créé, notez la "Procédure de montage Amazon EC2 (à partir de votre VPC local)". Nous utiliserons ces étapes plus tard lors du montage de cet EFS sur deux nœuds HA (PartyB Hot / Cold).

E. Création de RDS (PostgreSQL sur AWS) et définition de modèles

A propos de la création d'une instance PostgreSQL

Créez une instance PostgreSQL sur AWS. (La procédure de réglage est omise) Voici quelques remarques.

D'après le site officiel de Corda, PostgreSQL 9.6 avec JDBC Driver 42.1.4 a été testé. Dans cette vérification, j'ai utilisé PostgreSQL 10 en utilisant le même pilote, mais cela fonctionnait normalement sans aucun problème. https://docs.corda.r3.com/releases/3.3/node-database.html?highlight=node%20database%20developer#postgresql
Définissez les paramètres de sous-réseau et de groupe de sécurité de l'instance de base de données comme les paramètres des nœuds LB et Party B.
Notez le nom du point de terminaison de l'instance de base de données nouvellement créée. Ceci sera utilisé pour la configuration ultérieure (section F).

À propos de la configuration d'une instance PostgreSQL

Utilisez un outil client de connexion DB tiers tel que pgAdmin4 pour vous connecter à l'instance DB créée ci-dessus. Connectez-vous à l'instance de base de données en tant qu'administrateur et créez une base de données.
Créez un utilisateur de nœud et un schéma à l'aide du script officiel.

(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";

Après avoir exécuté le script ci-dessus, le schéma sera créé dans la base de données créée.

F. Paramètres des nœuds

Le contenu du réglage défini pour la vérification cette fois est décrit.

Ajoutez des informations sur les paramètres HA au fichier build.gradle.

Afin de configurer un nœud (par exemple, PartyB) pour les paramètres HA, il vous suffit de modifier les informations de configuration pertinentes pour ce nœud. Ce qui suit est une description comprenant des notes.

build.gradle

…<Abréviation>…
node {
        name "O=PartyB,L=Tokyo,C=JP"
        p2pAddress "internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008"
        //L'adresse ci-dessus est le nom DNS de l'équilibreur de charge créé à la section C.
        //Les autres nœuds Corda sont PartyB (Hot) via l'équilibreur de charge ci-dessus/Cold) Connectez-vous au nœud.
        rpcSettings {
            address("0.0.0.0:10009")
            adminAddress("0.0.0.0:10049")
        }
        //adresse rpc 0.0.0.Attribuer à 0. En effet, ces adresses sont utilisées par le nœud lui-même au démarrage et n'ont pas besoin d'être accédées par d'autres nœuds.
        //De plus, comme indiqué sur le site officiel, si vous la définissez sur l'adresse IP de la machine frontale, vous pouvez obtenir l'erreur "Impossible d'attribuer l'adresse demandée".
        extraConfig = [
                jarDirs : ["/***/***/"],
                //Pilote "postgresql-42.1.4.Veuillez définir le répertoire où se trouve jar ”.
                "dataSourceProperties.dataSource.url": "jdbc:postgresql://ce4-pgsql.************.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2",
                //DataSource ci-dessus.url est le point de terminaison de la base de données (créé dans la section E)/Numéro de port du serveur PGSQL (la valeur par défaut est 5432)/Nom de la base de données (créé dans la section E).
                "dataSourceProperties.dataSourceClassName": "org.postgresql.ds.PGSimpleDataSource",
                "dataSourceProperties.dataSource.user": "*****",
                "dataSourceProperties.dataSource.password": "*****",
                "database.transactionIsolationLevel": "READ_COMMITTED",
                "database.schema": "my_schema",
                "database.runMigration": "true"
                //Pour pouvoir créer les tables requises au démarrage du nœud, base de données.runMigration Défini sur "true".
        ]
        cordapps = [
                "$project.group:cordapp-contracts-states:$project.version",
                "$project.group:cordapp:$project.version"
        ]
        rpcUsers = [[ user: "user1", "password": "test", "permissions": ["ALL"]]]
    }
…<Abréviation>…

Construire et déployer G. CorDapps

Enregistrez le fichier <build.gradle> modifié ci-dessus et exécutez "./gradlew deployNodes" dans le répertoire CorDapps pour démarrer la compilation de CorDapps.

Si CorDapps se compile avec succès, vous verrez un message similaire à celui ci-dessous.

…<Abréviation>…
node {
        name "O=PartyB,L=Tokyo,C=JP"
        p2pAddress "internal-PartyB-HA-LB-*********.ap-northeast-1.elb.amazonaws.com:10008"
        //L'adresse ci-dessus est le nom DNS de l'équilibreur de charge créé à la section C.
        //Les autres nœuds Corda sont PartyB (Hot) via l'équilibreur de charge ci-dessus/Cold) Connectez-vous au nœud.
        rpcSettings {
            address("0.0.0.0:10009")
            adminAddress("0.0.0.0:10049")
        }
        //adresse rpc 0.0.0.Attribuer à 0. En effet, ces adresses sont utilisées par le nœud lui-même au démarrage et n'ont pas besoin d'être accédées par d'autres nœuds.
        //De plus, comme indiqué sur le site officiel, si vous la définissez sur l'adresse IP de la machine frontale, vous pouvez obtenir l'erreur "Impossible d'attribuer l'adresse demandée".
        extraConfig = [
                jarDirs : ["/***/***/"],
                //Pilote "postgresql-42.1.4.Veuillez définir le répertoire où se trouve jar ”.
                "dataSourceProperties.dataSource.url": "jdbc:postgresql://ce4-pgsql.************.ap-northeast-1.rds.amazonaws.com:5432/PartyB_HA2",
                //DataSource ci-dessus.url est le point de terminaison de la base de données (créé dans la section E)/Numéro de port du serveur PGSQL (la valeur par défaut est 5432)/Nom de la base de données (créé dans la section E).
                "dataSourceProperties.dataSourceClassName": "org.postgresql.ds.PGSimpleDataSource",
                "dataSourceProperties.dataSource.user": "*****",
                "dataSourceProperties.dataSource.password": "*****",
                "database.transactionIsolationLevel": "READ_COMMITTED",
                "database.schema": "my_schema",
                "database.runMigration": "true"
                //Pour pouvoir créer les tables requises au démarrage du nœud, base de données.runMigration Défini sur "true".
        ]
        cordapps = [
                "$project.group:cordapp-contracts-states:$project.version",
                "$project.group:cordapp:$project.version"
        ]
        rpcUsers = [[ user: "user1", "password": "test", "permissions": ["ALL"]]]
    }
…<Abréviation>…

Les répertoires de tous les nœuds corda, y compris PartyB, sont désormais créés sous «build / nodes». Le fichier node.conf de PartyB ressemble à ceci:

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
                }
            ]
        }
    }
}

De plus, la base de données contient toutes les tables nécessaires à Corda.

Veuillez noter que les autres tables requises par CorDapps n'ont pas encore été créées. Cela sera discuté plus loin dans la section I.

Copiez ensuite le répertoire de chaque nœud corda sur le serveur correspondant. .. Dans cet article, nous allons copier dans l'instance EC2 de chaque nœud corda. Copiez le répertoire du nœud HA (PartyB) dans les deux instances EC2 (HA-Hot (AZ1) et HA-Cold (AZ1)) que vous avez ajoutées à l'équilibreur de charge à l'étape 4 de la section C.

https://gist.github.com/luomin/263460bc930bc30ab719dd390394016c#file-logs-in-partyb-cold-node-txn-b

H. Configurez un lecteur partagé pour le nœud HA.

Connectez-vous à l'instance EC2 pour les deux Party Bs ci-dessus. Complétez les paramètres suivants pour les deux instances.

Si le répertoire nommé "artemis" n'existe pas sous le répertoire PartyB, créez-le.

mkdir artemis

Montez le lecteur EFS dans le répertoire "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

// Voir la note de la Session D pour voir ce qui précède. ..

Assurez-vous que le propriétaire du répertoire "artemis" est le même que le propriétaire de ce nœud corda.

e.g. chown ubuntu:ubuntu artemis

S'ils ne sont pas les mêmes, vous verrez une erreur similaire à la suivante lors du lancement du nœud PartyB:

---------- 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]

Le pilote JDBC sur l'instance EC2 peut se trouver dans un répertoire différent, vérifiez donc que la valeur "jarDirs" dans node.conf de PartyB est correcte. Veuillez corriger si nécessaire.

I. Démarrer tous les nœuds corda

Connectez-vous à toutes les instances EC2 et accédez au répertoire de nœuds corda que vous y avez copié.

Exécutez "java -jar corda.jar" dans ce répertoire pour démarrer le nœud corda

Cependant, lorsque vous démarrez le nœud HA (PartyB), vous pouvez voir un message d'erreur semblable au suivant:

------------------ 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]

Cela est dû au fait que le schéma / les tables requis pour CorDapps n'ont pas été créés dans PostgreSQL DB, comme décrit dans la section G.

Pour créer le "script de migration" requis, exécutez la commande suivante dans le répertoire de travail de la section G (l'environnement dans lequel vous créez CorDapp).


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

Le site Web officiel de Corda contient des instructions pour ces commandes. https://docs.corda.r3.com/database-management.html?highlight=node%20migration#adding-database-migration-scripts-retrospectively-to-an-existing-cordapp

Le script de migration est créé sous forme de fichier .jar situé dans le répertoire CorDapps de PartyB.

Vous avez maintenant créé le schéma requis pour les CorDapps dans PostgreSQL DB. Par exemple, la table «qd_states» requise par CorDapp utilisée dans cet article a été nouvellement créée.

L'instance EC2 HA-Hot (AZ1) lance maintenant avec succès le nœud PartyB avec un message de console similaire au suivant: HA-Cold (AZ1) sera dans l'état d'attente de démarrage.

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>>>

J. Tester la fonctionnalité HA

Tous les nœuds de codeur sont maintenant lancés avec succès sur l'instance EC2, comme le montre la figure 1.

Par exemple, si vous émettez une transaction (txn-a) entre PartyA et PartyB, txn-a se termine avec succès. Si vous vérifiez le fichier journal du nœud PartyA, il est enregistré que PartyA s'est réellement connecté à l'équilibreur de charge et connecté à PartyB:

[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)

Vous pouvez également voir que le nœud actif de PartyB traite le txn-a ci-dessus avec PartyA.

[INFO ] 2019-05-23T05:37:25,681Z [Node thread-1] internal.Node.registerJolokiaReporter - Registering Jolokia JMX reporter: {}
//Dans Cold Node de PartyB, txn-Il n'y a pas d'informations de journal sur un

logs in PartyB cold (txn-a)

[INFO ] 2019-05-23T05:26:59,167Z [Node thread-1] internal.Node.registerJolokiaReporter - Registering Jolokia JMX reporter: {}
//Après cela, txn-C'est un journal d'un fichier.
[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)

Arrêtez ensuite le Hot Node de PartyB et émettez une seconde transaction (txn-b).

Vous pouvez confirmer que TXN-B peut également être exécuté normalement.

En passant, si vous vérifiez le journal de PartyA, vous pouvez voir que PartyA détecte que PartyB a été déconnecté immédiatement après l'arrêt du nœud actif de PartyB et se reconnecte à l'équilibreur de charge de PartyB.

[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.

Vous trouverez ci-dessous le journal du parti A Txn-b. Cela indique que PartyA a bien reçu la signature PartyB (Cold).

[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

Vous trouverez ci-dessous le journal Txn-b pour Party B Cold Node. Cela indique que PartyB (Cold) a reçu txn-b de PartyA et l'a traité normalement.

[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

Lorsque PartyB (chaud) qui a été arrêté est redémarré, si PartyB (froid) est à l'état actif, le processus Corda ne démarrera pas et sera dans un état d'attente. Par conséquent, lorsque la troisième transaction (txn-c) est émise, txn-c est traité normalement par PartyB (à froid).

Commentaire général

Même si une panne se produit dans le nœud actif, le nœud inactif démarrera automatiquement, et pendant qu'il démarre, il attendra un moment, mais comme les transactions peuvent être traitées sans interruption, nous pensons que la haute disponibilité peut être garantie. Cependant, il s'agit d'une haute disponibilité de nœud uniquement. Du point de vue du système, les nœuds, les équilibreurs de charge, les lecteurs réseau partagés, les bases de données, sont toutes les ressources nécessaires à un nœud Corda, et si l'un d'entre eux tombe en panne, il ne fonctionnera pas comme un nœud Corda. La haute disponibilité de l'ensemble du système ne peut être garantie que si une configuration de cluster HA est créée pour toutes les ressources requises.

Résumé

Cet article décrit les étapes et les précautions requises pour créer un nœud HA Corda dans un environnement AWS.

La dernière version de Corda Enterprise (CE4.0) offre une approche alternative pour configurer les nœuds HA sans équilibreur de charge. Dans le prochain article, je publierai comment définir la fonction.

Remarque: TIS Blockchain Promotion Office (Ra)

Thanks to Kiyotaka Yamasaki.

Demandes de renseignements sur cet article: SBI R3 Japan [email protected]

[JAVA] Haute disponibilité (HA) du nœud R3 Corda et comment le configurer