github.com/hechain20/hechain@v0.0.0-20220316014945-b544036ba106/docs/source/deployorderer/ordererchecklist.md (about)

     1  # Checklist for a production ordering node
     2  
     3  As you prepare to build a production ordering service (or a single ordering node), you need to customize the configuration by editing the [orderer.yaml](https://github.com/hechain20/hechain/blob/{BRANCH}/sampleconfig/orderer.yaml) file, which is copied into the `/config` directory when downloading the Fabric binaries, and available within the Fabric ordering node image at `/etc/hyperledger/fabric/orderer.yaml`.
     4  
     5  While in a production environment you could override the environment variables in the `orderer.yaml` file in your Docker container or your Kubernetes job, these instructions show how to edit `orderer.yaml` instead. It’s important to understand the parameters in the configuration file and their dependencies on other parameter settings in the file. Blindly overriding one setting using an environment variable could affect the functionality of another setting. Therefore, the recommendation is that before starting the ordering node, you make the modifications to the settings in the configuration file to become familiar with the available settings and how they work. Afterwards, you may choose to override these parameters using environment variables.
     6  
     7  This checklist covers key configuration parameters for setting up a production ordering service. Of course, you can always refer to the orderer.yaml file for additional parameters or more information. It also provides guidance on which parameters should be overridden. The list of parameters that you need to understand and that are described in this topic include:
     8  
     9  * [General.ListenAddress](#general-listenaddress)
    10  * [General.ListenPort](#general-listenport)
    11  * [General.TLS.*](#general-tls)
    12  * [General.Keepalive.*](#general-keepalive)
    13  * [General.Cluster.*](#general-cluster)
    14  * [General.BoostrapMethod](#general-bootstrapmethod)
    15  * [General.BoostrapFile](#general-bootstrapfile)
    16  * [General.LocalMSPDir](#general-localmspdir)
    17  * [General.LocalMSPID](#general-localmspid)
    18  * [FileLedger.Location](#fileledger-location)
    19  * [Operations.*](#operations)
    20  * [Metrics.*](#metrics)
    21  * [Admin.*](#admin)
    22  * [ChannelParticipation.*](#channelparticipation)
    23  * [Consensus.*](#consensus)
    24  
    25  ## General.ListenAddress
    26  
    27  ```
    28  # Listen address: The IP on which to bind to listen.
    29  ListenAddress: 127.0.0.1
    30  ```
    31  
    32  * **`ListenAddress`**: (default value should be overridden) This is the location where the orderer will listen, for example, `0.0.0.0`. Note: unlike the peer, the `orderer.yaml` separates the address and the port, hence the [General.ListenPort](#general-listenport) parameter.
    33  
    34  ## General.ListenPort
    35  
    36  ```
    37  # Listen port: The port on which to bind to listen.
    38  ListenPort: 7050
    39  ```
    40  
    41  * **`ListenPort`**: (default value should be overridden) This is the port that the orderer listens on.
    42  
    43  ## General.TLS
    44  
    45  ```
    46  # Require server-side TLS
    47  Enabled: false
    48  # PrivateKey governs the file location of the private key of the TLS certificate.
    49  PrivateKey: tls/server.key
    50  # Certificate governs the file location of the server TLS certificate.
    51  Certificate: tls/server.crt
    52  # RootCAs contains a list additional root certificates used for verifying certificates
    53  # of other orderer nodes during outbound connections.
    54  # It is not required to be set, but can be used to augment the set of TLS CA certificates
    55  # available from the MSPs of each channel’s configuration.
    56  RootCAs:
    57    - tls/ca.crt
    58  # Require client certificates / mutual TLS for inbound connections.
    59  ClientAuthRequired: false
    60  # If mutual TLS is enabled, ClientRootCAs contains a list of additional root certificates
    61  # used for verifying certificates of client connections.
    62  # It is not required to be set, but can be used to augment the set of TLS CA certificates
    63  # available from the MSPs of each channel’s configuration.
    64  ClientRootCAs:
    65  ```
    66  
    67  * **`Enabled`**: (default value should be overridden) In a production network, you should be using TLS-secured communications. This value should be `true`.
    68  * **`PrivateKey`**: (default value should be overridden). Provide the path to, and filename of, the private key generated by your TLS CA for this node.
    69  * **`Certificate`**: (default value should be overridden) Provide the path to, and filename of, the public certificate (also known as the sign certificate) generated by your TLS CA for this node.
    70  * **`RootCAs`**: (should be commented out) This parameter is typically unset for normal use. It is a list of the paths to additional root certificates used for verifying certificates of other orderer nodes during outbound connections. It can be used to augment the set of TLS CA certificates available from the MSPs of each channel's configuration.
    71  * **`ClientAuthRequired`**: (Mutual TLS only) Setting this value to “true” will enable mutual TLS on your network, and must be done for the entire network, not just one node.
    72  * **`ClientRootCAs`**: (Mutual TLS only) Can be left blank if mutual TLS is disabled. If mutual TLS is enabled, this is a list of the paths to additional root certificates used for verifying certificates of client connections. It can be used to augment the set of TLS CA certificates available from the MSPs of each channel’s configuration.
    73  
    74  ## General.KeepAlive
    75  
    76  The `KeepAlive` values might need to be tuned for compatibility with any networking devices or software (like firewalls or proxies) in between components of your network. Ideally, these settings would be manipulated if needed in a test or pre-prod environment and then set accordingly for your production environment.
    77  
    78  ```
    79  # ServerMinInterval is the minimum permitted time between client pings.
    80  # If clients send pings more frequently, the server will
    81  # disconnect them.
    82  ServerMinInterval: 60s
    83  # ServerInterval is the time between pings to clients.
    84  ServerInterval: 7200s
    85  # ServerTimeout is the duration the server waits for a response from
    86  # a client before closing the connection.
    87  ServerTimeout: 20s
    88  ```
    89  
    90  * **`ServerMinInterval`**: (default value should not be overridden, unless determined necessary through testing)
    91  * **`ServerInterval`**: (default value should not be overridden, unless determined necessary through testing)
    92  * **`ServerTimeout`**: (default value should not be overridden, unless determined necessary through testing)
    93  
    94  ## General.Cluster
    95  
    96  ```
    97  # SendBufferSize is the maximum number of messages in the egress buffer.
    98  # Consensus messages are dropped if the buffer is full, and transaction
    99  # messages are waiting for space to be freed.
   100  SendBufferSize: 10
   101  # ClientCertificate governs the file location of the client TLS certificate
   102  # If not set, the server General.TLS.Certificate is re-used.
   103  ClientCertificate:
   104  # If not set, the server General.TLS.PrivateKey is re-used.
   105  ClientPrivateKey:
   106  # The below 4 properties should be either set together, or be unset together.
   107  # If they are set, then the orderer node uses a separate listener for intra-cluster
   108  # communication. If they are unset, then the general orderer listener is used.
   109  # This is useful if you want to use a different TLS server certificates on the
   110  # client-facing and the intra-cluster listeners.
   111  
   112  # ListenPort defines the port on which the cluster listens to connections.
   113  ListenPort:
   114  # ListenAddress defines the IP on which to listen to intra-cluster communication.
   115  ListenAddress:
   116  # ServerCertificate defines the file location of the server TLS certificate used for intra-cluster
   117  # communication.
   118  ServerCertificate:
   119  # ServerPrivateKey defines the file location of the private key of the TLS certificate.
   120  ServerPrivateKey:
   121  ```
   122  
   123  If unset, the `ClientCertificate` and `ClientPrivateKey` default to the server `General.TLS.Certificate` and `General.TLS.PrivateKey` when the orderer is not configured to use a separate cluster port.
   124  
   125  * **`ClientCertificate`**:  Provide the path to, and filename of, the public certificate (also known as a signed certificate) generated by your TLS CA for this node.
   126  * **`ClientPrivateKey`**: Provide the path to, and filename of, the private key generated by your TLS CA for this node.
   127  
   128  In general, these four parameters would only need to be configured if you want to configure a separate listener and TLS certificates for intra-cluster communication (with other Raft orderers), as opposed to using the listener that peer clients and application clients utilize. This is an advanced deployment option. These four parameters should be set together or left unset, and if they are set, note that the `ClientCertificate` and `ClientPrivateKey` must be set as well.
   129  
   130  * **`ListenPort`**
   131  * **`ListenAddress`**
   132  * **`ServerCertificate`**
   133  * **`ServerPrivateKey`**
   134  
   135  ## General.BoostrapMethod
   136  
   137  ```
   138  # Bootstrap method: The method by which to obtain the bootstrap block
   139  # system channel is specified. The option can be one of:
   140  #   "file" - path to a file containing the genesis block or config block of system channel
   141  #   "none" - allows an orderer to start without a system channel configuration
   142  BootstrapMethod: file
   143  ```
   144  
   145  * **`BootstrapMethod`**: If you plan to create this node on a network that is not using a system channel, override this value to `none` and then ensure that [`ChannelParticipation.Enabled`](#channelparticipation) is set to `true`, otherwise you will get an error when you attempt to start the node. If you are creating a node to be joined to a system channel, unless you plan to use a file type other than “file”, this value should be left as is.
   146  
   147  ## General.BoostrapFile
   148  
   149  ```
   150  # Bootstrap file: The file containing the bootstrap block to use when
   151  # initializing the orderer system channel and BootstrapMethod is set to
   152  # "file".  The bootstrap file can be the genesis block, and it can also be
   153  # a config block for late bootstrap of some consensus methods like Raft.
   154  # Generate a genesis block by updating $FABRIC_CFG_PATH/configtx.yaml and
   155  # using configtxgen command with "-outputBlock" option.
   156  # Defaults to file "genesisblock" (in $FABRIC_CFG_PATH directory) if not specified.
   157  BootstrapFile:
   158  ```
   159  
   160  * **`BoostrapFile`**: (if you are creating this node to be joined to a system channel, the default value should be overridden) Specify the location and name of the system channel genesis block to use when this node is created. If you are creating this node without using a system channel, this value will not be used, and can therefore be left blank.
   161  
   162  ## General.LocalMSPDir
   163  
   164  ```
   165  # LocalMSPDir is where to find the private crypto material needed by the
   166  # orderer. It is set relative here as a default for dev environments but
   167  # should be changed to the real location in production.
   168  LocalMSPDir: msp
   169  ```
   170  
   171  **`LocalMSPDir`**: (default value will often be overridden) This is the path to the ordering node's local MSP, which must be created before it can be deployed. The path can be absolute or relative to `FABRIC_CFG_PATH` (by default, it is `/etc/hyperledger/fabric` in the orderer image). Unless an absolute path is specified to a folder named something other than "msp", the ordering node defaults to looking for a folder called “msp” at the path (in other words, `FABRIC_CFG_PATH/msp`) and when using the orderer image: `/etc/hyperledger/fabric/msp`. If you are using the recommended folder structure described in the [Registering and enrolling identities with a CA](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/deployguide/use_CA.html) topic, it would be relative to the `FABRIC_CFG_PATH` as follows:
   172  `config/organizations/ordererOrganizations/org0.example.com/orderers/orderer0.org0.example.com/msp`. **The best practice is to store this data in persistent storage**. This prevents the MSP from being lost if your orderer containers are destroyed for some reason.
   173  
   174  ## General.LocalMSPID
   175  
   176  ```
   177  # LocalMSPID is the identity to register the local MSP material with the MSP
   178  # manager. IMPORTANT: The local MSP ID of an orderer needs to match the MSP
   179  # ID of one of the organizations defined in the orderer system channel's
   180  # /Channel/Orderer configuration. The sample organization defined in the
   181  # sample configuration provided has an MSP ID of "SampleOrg".
   182  LocalMSPID: SampleOrg
   183  ```
   184  
   185  * **`LocalMSPID`**: (default value should be overridden) This identifies the organization this ordering node belongs to. The MSP ID must match the orderer organization MSP ID that exists in the configuration of any channel this joined will be joined to.
   186  
   187  ## General.BCCSP.*
   188  
   189  ```
   190  # Default specifies the preferred blockchain crypto service provider
   191          # to use. If the preferred provider is not available, the software
   192          # based provider ("SW") will be used.
   193          # Valid providers are:
   194          #  - SW: a software based crypto provider
   195          #  - PKCS11: a CA hardware security module crypto provider.
   196          Default: SW
   197  
   198          # SW configures the software based blockchain crypto provider.
   199          SW:
   200              # TODO: The default Hash and Security level needs refactoring to be
   201              # fully configurable. Changing these defaults requires coordination
   202              # SHA2 is hardcoded in several places, not only BCCSP
   203              Hash: SHA2
   204              Security: 256
   205              # Location of key store. If this is unset, a location will be
   206              # chosen using: 'LocalMSPDir'/keystore
   207              FileKeyStore:
   208                  KeyStore:
   209  ```
   210  
   211  (Optional) This section is used to configure the Blockchain crypto provider.
   212  
   213  * **`BCCSP.Default:`** If you plan to use a Hardware Security Module (HSM), then this must be set to `PKCS11`.
   214  
   215  ```
   216  # Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11)
   217          PKCS11:
   218              # Location of the PKCS11 module library
   219              Library:
   220              # Token Label
   221              Label:
   222              # User PIN
   223              Pin:
   224              Hash:
   225              Security:
   226              FileKeyStore:
   227                  KeyStore:
   228  ```
   229  
   230  * **`BCCSP.PKCS11.*:`** Provide this set of parameters according to your HSM configuration. Refer to this [example](../hsm.html) of an HSM configuration for more information.
   231  
   232  ## FileLedger.Location
   233  
   234  ```
   235  # Location: The directory to store the blocks in.
   236  Location: /var/hyperledger/production/orderer
   237  ```
   238  
   239  * **`Location`**: (default value should be overridden in the unlikely event where two ordering nodes are running on the same node) Every channel on which the node is a consenter will have its own subdirectory at this location. The user running the orderer needs to own and have write access to this directory. **The best practice is to store this data in persistent storage**. This prevents the ledger from being lost if your orderer containers are destroyed for some reason.
   240  
   241  ## Operations.*
   242  
   243  The operations service is used for monitoring the health of the ordering node and relies on mutual TLS to secure its communication. Therefore, you need to set `operations.tls.clientAuthRequired` to `true`. When this parameter is set to `true`, clients attempting to ascertain the health of the node are required to provide a valid certificate for authentication. If the client does not provide a certificate or the service cannot verify the client’s certificate, the request is rejected. This means that the clients will need to register with the ordering node's TLS CA and provide their TLS signing certificate on the requests. See [The Operations Service](../operations_service.html) to learn more.
   244  
   245  If you plan to use Prometheus [metrics](#metrics) to monitor your ordering node, you must configure the operations service here.
   246  
   247  In the unlikely case where two ordering nodes are running on the same node on your infrastructure, you need to modify the addresses for the second ordering node to use a different port. Otherwise, when you start the second ordering node, it will fail to start, reporting that the addresses are already in use.
   248  
   249  ```
   250  # host and port for the operations server
   251      ListenAddress: 127.0.0.1:8443
   252  
   253      # TLS configuration for the operations endpoint
   254      TLS:
   255          # TLS enabled
   256          Enabled: false
   257  
   258          # Certificate is the location of the PEM encoded TLS certificate
   259          Certificate:
   260  
   261          # PrivateKey points to the location of the PEM-encoded key
   262          PrivateKey:
   263  
   264          # Most operations service endpoints require client authentication when TLS
   265          # is enabled. ClientAuthRequired requires client certificate authentication
   266          # at the TLS layer to access all resources.
   267          ClientAuthRequired: false
   268  
   269          # Paths to PEM encoded ca certificates to trust for client authentication
   270          ClientRootCAs: []
   271  ```
   272  
   273  * **`ListenAddress`**: (required when using the operations service) Specify the address and port of the operations server.
   274  * **`Enabled`**: (required when using the operations service) Must be `true` if the operations service is being used.
   275  * **`Certificate`**: (required when using the operations service) Can be the same file as the `General.TLS.Certificate`.
   276  * **`PrivateKey`**: (required when using the operations service) Can be the same file as the `General.TLS.PrivateKey`.
   277  * **`ClientAuthRequired`**: (required when using the operations service) Must be set to `true` to enable mutual TLS between the client and the server.
   278  * **`ClientRootCAs`**: (required when using the operations service) Similar to the client root CA cert file in TLS, it contains a list of client root CA certificates that can be used to verify client certificates. If the client enrolled with the orderer organization CA, then this value is the orderer organization root CA cert.
   279  
   280  ## Metrics.*
   281  
   282  By default this is disabled, but if you want to monitor the metrics for the orderer, you need to use `StatsD` or `Prometheus` as your metric provider. `StatsD` uses a "push" model, pushing metrics from the ordering node to a `StatsD` endpoint. Because of this, it does not require configuration of the operations service itself. `Prometheus` metrics, by contrast, are pulled from an ordering node.
   283  
   284  For more information about the available `Prometheus` metrics, check out [Prometheus](../metrics_reference.html#prometheus)
   285  
   286  For more information about the available `StatsD` metrics, check out [StatsD](../metrics_reference.html#statsd).
   287  
   288  Because Prometheus utilizes a "pull" model there is not any configuration required, beyond making the operations service available. Rather, Prometheus will send requests to the operations URL to poll for available metrics.
   289  
   290  ```
   291      # The metrics provider is one of statsd, prometheus, or disabled
   292      Provider: disabled
   293  
   294      # The statsd configuration
   295      Statsd:
   296        # network type: tcp or udp
   297        Network: udp
   298  
   299        # the statsd server address
   300        Address: 127.0.0.1:8125
   301  
   302        # The interval at which locally cached counters and gauges are pushed
   303        # to statsd; timings are pushed immediately
   304        WriteInterval: 30s
   305  
   306        # The prefix is prepended to all emitted statsd metrics
   307        Prefix:
   308  ```
   309  
   310  * **`Provider`**: Set this value to `statsd` if using `StatsD` or `prometheus` if using `Prometheus`.
   311  * **`Statsd.Address`**: (required to use `StatsD` metrics for the ordering node) When `StatsD` is enabled, you will need to configure the `hostname` and `port` of the `StatsD` server so that the ordering node can push metric updates.
   312  
   313  ## Admin.*
   314  
   315  ```
   316  Admin:
   317      # host and port for the admin server
   318      ListenAddress: 127.0.0.1:9443
   319  
   320      # TLS configuration for the admin endpoint
   321      TLS:
   322          # TLS enabled
   323          Enabled: false
   324  
   325          # Certificate is the location of the PEM encoded TLS certificate
   326          Certificate:
   327  
   328          # PrivateKey points to the location of the PEM-encoded key
   329          PrivateKey:
   330  
   331          # Most admin service endpoints require client authentication when TLS
   332          # is enabled. ClientAuthRequired requires client certificate authentication
   333          # at the TLS layer to access all resources.
   334          #
   335          # NOTE: When TLS is enabled, the admin endpoint requires mutual TLS. The
   336          # orderer will panic on startup if this value is set to false.
   337          ClientAuthRequired: true
   338  
   339          # Paths to PEM encoded ca certificates to trust for client authentication
   340          ClientRootCAs: []
   341  ```
   342  
   343  * **`ListenAddress`**: The orderer admin server address (host and port) that can be used by the `osnadmin` command to configure channels on the ordering service. This value should be a unique `host:port` combination to avoid conflicts.
   344  * **`TLS.Enabled`**: Technically this can be set to `false`, but this is not recommended. In general, you should always set this value to `true`.
   345  * **`TLS.Certificate`**: The path to and file name of the orderer signed certificate issued by the TLS CA.
   346  * **`TLS.PrivateKey`**: The path to and file name of the orderer private key issued by the TLS CA.
   347  * **`TLS.ClientAuthRequired`**: This value must be set to `true`. Note that while mutual TLS is required for all operations on the orderer `Admin` endpoint, the entire network is not required to use mutual TLS.
   348  * **`TLS.ClientRootCAs`**: The path to and file name of the admin client TLS CA root certificate.
   349  
   350  ## ChannelParticipation.*
   351  
   352  ```
   353  ChannelParticipation:
   354      # Channel participation API is enabled.
   355      Enabled: false
   356  
   357      # The maximum size of the request body when joining a channel.
   358      MaxRequestBodySize: 1 MB
   359  ```
   360  
   361  * **`Enabled`**: If you are bootstrapping the ordering node with a system channel genesis block, this value can be set to either `true` or `false` (setting the value to `true` allows you to list channels and to migrate away from the system channel in the future). If you are **not** bootstrapping the ordering node with a system channel genesis block, this value must be set to `true` and the [`General.BoostrapMethod`](#general-boostrapmethod) should be set to `none`.
   362  * **`MaxRequestBodySize`**: (default value should not be overridden) This value controls the maximum size a configuration block can be and be accepted by this ordering node. Most configuration blocks are smaller than 1 MB, but if for some reason a configuration block is too large to be accept, bring down the node, increase this value, and restart the node.
   363  
   364  ## Consensus.*
   365  
   366  The values of this section vary by consensus plugin. The values below are for the `etcdraft` consensus plugin. If you are using a different consensus plugin, refer to its documentation for allowed keys and recommended values.
   367  
   368  ```
   369  # The allowed key-value pairs here depend on consensus plugin. For etcd/raft,
   370  # we use following options:
   371  
   372  # WALDir specifies the location at which Write Ahead Logs for etcd/raft are
   373  # stored. Each channel will have its own subdir named after channel ID.
   374  WALDir: /var/hyperledger/production/orderer/etcdraft/wal
   375  
   376  # SnapDir specifies the location at which snapshots for etcd/raft are
   377  # stored. Each channel will have its own subdir named after channel ID.
   378  SnapDir: /var/hyperledger/production/orderer/etcdraft/snapshot
   379  ```
   380  
   381  * **`WALDir`**: (default value should be overridden) This is the path to the write ahead logs on the local filesystem of the ordering node. It can be an absolute path or relative to `FABRIC_CFG_PATH`. It defaults to `/var/hyperledger/production/orderer/etcdraft/wal`. Each channel will have its own subdirectory named after the channel ID. The user running the ordering node needs to own and have write access to this directory. **The best practice is to store this data in persistent storage**. This prevents the write ahead log from being lost if your orderer containers are destroyed for some reason.
   382  * **`SnapDir`**: (default value should be overridden) This is the path to the snapshots on the local filesystem of the ordering node. For more information about how snapshots work in a Raft ordering service, check out [Snapshots](../orderer/ordering_service.html#snapshots)/ It can be an absolute path or relative to `FABRIC_CFG_PATH`. It defaults to `/var/hyperledger/production/orderer/etcdraft/wal`. Each channel will have its own subdirectory named after the channel ID. The user running the ordering node needs to own and have write access to this directory. **The best practice is to store this data in persistent storage**. This prevents snapshots from being lost if your orderer containers are destroyed for some reason.
   383  
   384  For more information about ordering node configuration, including how to set parameters that are not available in `orderer.yaml`, check out [Configuring and operating a Raft ordering service](../raft_configuration.html).
   385  
   386  <!--- Licensed under Creative Commons Attribution 4.0 International License
   387  https://creativecommons.org/licenses/by/4.0/) -->