ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-03-14 00:06:45 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

ENT-2147 HA doc review (#1096)

Browse Source 
* Corda to Corda Enterprise, remove CE source mention, CRL((certificate revocation list)
This commit is contained in:
cburlinchon 2018-06-27 16:08:22 +01:00 committed by GitHub
parent 8e75e78705
commit 72a29101c3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 11 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/source/bridge-configuration-file.rst
View File

@ -30,11 +30,8 @@ The Bridge configuration file uses the HOCON format which is superset of JSON. P
Defaults
--------
A set of default configuration options are loaded from the built-in resource file ``/bridge/src/main/resources/bridgedefault.conf``.
This file can be found in the ``:bridge`` gradle module of the `Enterprise Corda repository <https://github.com/corda/enterprise>`_. Any
options you do not specify in your own ``bridge.conf`` file will use these defaults.
Here are the contents of the ``bridgedefault.conf`` file:
A set of default configuration options are loaded from the built-in resource file. Any options you do not specify in
your own ``bridge.conf`` file will use these defaults:
.. literalinclude:: ../../bridge/src/main/resources/bridgedefault.conf
:language: javascript
@ -105,7 +102,7 @@ absolute path to the bridge's base directory.
:trustStoreFile: The path to the TrustStore file to use in outgoing ``TLS/AMQP 1.0`` connections.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL provider is unavailable.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.
:socksProxyConfig: This section is optionally present if outgoing peer connections should go via a SOCKS4, or SOCKS5 proxy:
@ -133,7 +130,7 @@ absolute path to the bridge's base directory.
:trustStoreFile: The path to the TrustStore file to use in inbound ``TLS/AMQP 1.0`` connections.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL provider is unavailable.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.
:bridgeInnerConfig: This section is required for ``BridgeInner`` mode and configures the tunnel connection to the ``FloatOuter`` (s) in the DMZ. The section should be absent in ``SenderReceiver`` and ``FloatOuter`` modes:
@ -154,7 +151,7 @@ absolute path to the bridge's base directory.
:trustStoreFile: The path to the TrustStore file to use in control tunnel connections.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL provider is unavailable.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.
:customFloatOuterSSLConfiguration: The keys and certificates for the ``FloatOuter`` are provisioned dynamically from the ``BridgeInner`` over the control tunnel and are not loaded from disk in the DMZ.
By default, they are taken from (``<workspace>/certificates/sslkeystore.jks``)
@ -168,7 +165,7 @@ absolute path to the bridge's base directory.
:trustStoreFile: The path to the TrustStore file to use in the ``FloatOuter`` when it activates the peer listening socket.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL provider is unavailable.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.
:floatOuterConfig: This section is required for ``FloatOuter`` mode and configures the control tunnel listening socket. It should be absent for ``SenderReceiver`` and ``BridgeInner`` modes:
@ -188,7 +185,7 @@ absolute path to the bridge's base directory.
:trustStoreFile: The path to the TrustStore file to use in control tunnel connections.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL provider is unavailable.
:crlCheckSoftFail: If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.
:haConfig: Optionally the ``SenderReceiver`` and ``BridgeInner`` modes can be run in a hot-warm configuration, which determines the active instance using an external master election service.
Currently, only Zookeeper can be used as master elector. Eventually other electors may be supported e.g. ``etcd``. This configuration section controls these options:

2
docs/source/corda-bridge-component.rst
View File

@ -7,7 +7,7 @@ Introduction
------------
The Corda bridge/float component is designed for enterprise deployments and acts as an application level
firewall and protocol break on all internet facing endpoints. The ``corda-bridgeserver.jar`` encapsulates the peer
network functionality of the basic Corda node, so that this can be operated separately from the security sensitive
network functionality of the basic Corda Enterprise node, so that this can be operated separately from the security sensitive
JVM runtime of the node. This gives separation of functionality and ensures that the legal identity keys are not
used in the same process as the internet TLS connections. Also, it adds support for enterprise deployment requirements,
such as High Availability (HA) and SOCKS proxy support.

6
docs/source/hot-cold-deployment.rst
View File

@ -7,7 +7,7 @@ Hot-cold deployment
Overview
--------
This section describes hot-cold availability of Corda nodes and their associated configuration setup. In such a set-up,
This section describes hot-cold availability of Corda Enterprise nodes and their associated configuration setup. In such a set-up,
there is one back-up instance that can be started if the primary instance stops. Each instance of Corda should be hosted
on a separate server and represent the same entity in the Corda network.
@ -23,7 +23,7 @@ In order to achieve this set-up, in addition to the physical nodes, a few other
This guide will cover all the steps required to configure and deploy the nodes as well as configuring the above mentioned
resources for both **Microsoft Azure** and **Amazon Web Services**. The image below illustrates the environment that will
result from following the guide. There will be two Corda nodes, one active and the other inactive. Each node will represent
result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent
the same legal identity inside the Corda network. Both will share a database and a network file system.
.. image:: resources/hot-cold.png
@ -32,7 +32,7 @@ Configuring the load balancer
-----------------------------
In a hot-cold environment, the load balancer is used to redirect incoming traffic (P2P, RPC and HTTP) towards the active
Corda node instance. The internet facing IP address of the load balancer will be advertised to the rest of the Corda network
Corda Enterprise node instance. The internet facing IP address of the load balancer will be advertised to the rest of the Corda network
by each node as their P2P addresses. This is done by configuring the load balancer IP as the node's P2P address in its
configuration file. The back-end pool of the load balancer should include both machines hosting the nodes to be able to redirect traffic to
them. A load balancing rule should be created for each port configured in the nodes' configuration files (P2P, RPC and HTTP).