Enabling and Validating TLS


#1

Enabling and Validating TLS

Introduction

Transport Layer Security (TLS), is a cryptographic protocol designed to provide secure communication over a network. Enabling TLS for the traffic between clients and Aerospike nodes requires changes to be made both on the Aerospike nodes and clients. This document provides the changes required to be made on the Aerospike nodes so that clients can communicate with the cluster via TLS enabled ports. In addition to providing the step by step procedure, the appendix of this document also provides a sample setup through which each step is executed and validated. The scope of this document covers Standard and Mutual authentication modes of TLS with cluster name match and validating with the C and Java clients.

Server Side Configuration

Procedure Overview

  1. Prerequisites:
  • Have the required specific certificates, private keys and signing CA certificates available.
  • Set the cluster nodes with a cluster-name [optional but recommended] .
  1. Introduce the TLS configuration parameters in the configuration file on one node and restart the Aerospike service.

  2. Repeat step 2 for all nodes in the cluster.

  3. Validate the TLS setup on the server side. At this point, applications will continue to communicate with the Aerospike cluster via clear ports.

  4. Ensure all clients have been updated to exclusively connect to the TLS port.

  5. Remove the non TLS port from the configuration and proceed with a rolling restart of the cluster.

1- Prerequisites

Certificate requirements

Standard authentication
  • Server certificate: A server certificate is a digital certificate issued to a server by a trusted certification authority (CA) containing a name, a signature and a public key. Sometimes, a server certificate may not be a single certificate but a chain of certificates. A certificate chain is an ordered list of certificates. The chain begins with the SSL certificate, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. Any certificate that sits between the OpenSSL certificate and the root certificate is called a chain or intermediate certificate. The intermediate certificate is the signer/issuer of the OpenSSL certificate. The root CA Certificate is the signer/issuer of the Intermediate Certificate. The cert-file configuration parameter must be set and point to this file. It is the all-in-one .pem file, which includes the server’s own certificate. If the certificate is chain-signed, it must also include the chained CA Certificate files in certificate chain order.

  • Server Key: This is the private key for the server certificate. The key-file configuration parameter must be set. It is the .pem file with the private key associated with the certificate.

  • The client must have the relevant root CA (Certificate Authority) certificate configured. A CA certificate has the same structure as a server certificate and contains a name, a signature and public key and is used to verify the server certificate has the right signature and is correct for its name.

  • For the example described here (cluster name matching), all Aerospike cluster nodes use same set of certificates.

  • The certificates must have cluster-name defined in the Subject/CN field. For example:

Subject: C=US, ST=California, L=San Jose, O=Acme, Inc., OU=Aerospike Cluster, CN=aerocluster
Mutual authentication

In addition to the files required for the client to authenticate the cluster nodes, the following files are required for the cluster nodes to authenticate the clients:

  • Client certificate: The certificate must be a valid certificate chain, and must be signed by the same CA (Certificate Authority) as the server.

  • Client Key: This is the private key for the client certificate.

  • Root CA certificate: The client’s signing CA certificate. The ca-file/ca-path configuration parameter must point to this file or path containing the relevant CA certificate.

Have the required specific certificates, private keys and signing CA certificates available.

Aerospike Server Enterprise Edition version 3.11 and above is required, but 3.15 and versions above are recommended.

Heartbeat protocol requirements and cluster-name setting

The cluster-name configuration parameter is available as of heartbeat protocol version 3. So, we need to ensure that all the Aerospike nodes are on heartbeat protocol V3. Please refer to the following article to change protocol version from V2 to V3.

Note: If running version 3.14 or above, the heartbeat protocol version would already be set to v3.

Perform the following steps through the asadm tool (for example from one of the nodes in the cluster). This ensures that the command is executed on all nodes in the cluster.

  1. Dynamically change the cluster name on the entire cluster using asadm:
Admin> asinfo -v 'set-config:context=service;cluster-name=aerocluster'
  1. Validate the cluster name change using asadm.
Admin> show config like cluster-name
  1. Ensure the stability of the cluster using asadm:
  • There are no migrations happening.
  • The size of the cluster is correct.

The info command within asadm shows the information about migrations and cluster size

Admin> info
  1. Edit the Aerospike configuration file (aerospike.conf) on each node to introduce the cluster-name configuration parameter in the service section. This ensures that the cluster-name configured dynamically doesn’t revert upon the subsequent restart of the Aerospike service. Replace the value of the parameter cluster-name with the custom value.
service {
    ... 
    cluster-name  aerocluster
    ...
}

2- Enable TLS on the cluster nodes

  1. Copy the certificates to all the Aerospike nodes in the cluster

  2. Introduce the TLS configuration parameters

Note: The following step refers to the section in the Aerospike configuration file: aerospike.conf. As each Aerospike node has an individual configuration file, these steps must be performed on each node.

Standard authentication
  • network / tls section:

    • Add a tls sub-stanza named <cluster-name> with the following 2 entries:
      • The value for cert-file must be the path to server certificate.
      • The value for key-file must be the path to key file.
  • network / service section:

    • Set the tls-address configuration parameter to the bind address for TLS (the IP address at which the server listens for client connections, defaults to any if not set, which will bind to all available interfaces).
    • Set the tls-port.
    • tls-authenticate-client must be set to false (for older server versions, tls-mode must be authenticate-server)
    • tls-name picks up the cluster-name mentioned in the service section when a value of <cluster-name> is specified and will correlate the settings from the relevant tls sub-stanza.
  • Example configuration:

network {
  tls <cluster-name> {
     cert-file /home/user/cluster_chain.pem
     key-file /home/user/key.pem
  }
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-name <cluster-name>
      tls-authenticate-client false
      ...
  }
}
  • For server versions prior to 3.15, the configuration is slightly different:
network {
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-mode authenticate-server
      tls-name <cluster-name>
      tls-certfile /home/user/cluster_chain.pem
      tls-keyfile /home/user/key.pem
      ... 
  }
...
}
Mutual authentication
  • network / service section - on top of the previously mentioned configuration settings:

  • Example configuration:

network {
  tls <cluster-name> {
     cert-file /home/user/cluster_chain.pem
     key-file /home/user/key.pem
     ca-file /etc/aerospike/certs/rootCA.pem
  }
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-name <cluster-name>
      tls-authenticate-client any
      ...
  }
}
  • For server versions prior to 3.15, the configuration is slightly different:
network {
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-mode authenticate-both
      tls-name <cluster-name>
      tls-certfile /home/user/cluster_chain.pem
      tls-keyfile /home/user/key.pem
      tls-cafile /home/user/rootCA.pem
      ... 
  }
...
}

3- Restart the node and repeat for each node in the cluster in a rolling manner

  1. Restart the aerospike service on this node
sudo service aerospike restart
  1. Ensure the stability of the cluster using asadm:
  • Make sure the size of the cluster is correct. The info command within asadm shows the information about migrations and cluster size.
Admin> info
  1. For versions prior to 3.13 running the older cluster protocol, you may want to wait or not wait for the migrations to complete before proceeding to the next node.

Note:

  1. To manage migrations refer to the migration tuning documentation.
  2. For further assistance, contact Aerospike support at: support@aerospike.com.

4- Validate the TLS setup on the server side.

At this point, applications will continue to communicate with the Aerospike cluster via clear ports. Before proceeding to the next step and enable TLS on the clients, a quick validation of the TLS enabled ports on the Aerospike nodes can be performed using one of the command line tools, asadm or aql.

Alternatively, try running some test loads using one of the client libraries as described next in this document.

Using the C benchmark tool

Run the traffic to Aerospike nodes via TLS enabled ports using the Aerospike C benchmark tool. Refer to the complete documentation on this page.

Standard Authentication

./target/benchmarks -h "<IP value>:<tls-name>:4333" --tlsEnable --tlsCaFile <Path to Root CA certificate>

Mutual Authentication

./target/benchmarks -h "<IP value>:<tls-name>:4333" --tlsEnable --tlsCaFile <Path to Root CA certificate> --tlsCertFile <Path to Client certificate> --tlsKeyFile <Path to key file>

Using the Java benchmark tool

Run the traffic to Aerospike nodes via TLS enabled ports using the Aerospike Java benchmark tool. Refer to the complete documentation on this page.

Standard Authentication

java -Djavax.net.ssl.trustStore=<Path to trustStore> -Djavax.net.ssl.trustStorePassword=<trustStore password> -jar target/aerospike-benchmarks-*-jar-with-dependencies.jar -h "<IP address>:<tls-name>:4333" -tlsEnable

Mutual Authentication

java -Djavax.net.ssl.trustStore=<Path to trustStore> -Djavax.net.ssl.trustStorePassword=<trustStore password> -Djavax.net.ssl.keyStore=<Path to KeyStore> -Djavax.net.ssl.keyStorePassword=<keyStore password> -jar target/aerospike-benchmarks-*-jar-with-dependencies.jar -h "<IP address>:<tls-name>:4333" -tlsEnable

5- Update all clients to exclusively connect to the TLS port

6- Remove the non TLS port from the configuration and proceed with a rolling restart of the cluster

Example with a Sample Environment

The following example of a sample environment is only provided as a reference and a validation to the above steps.

Note: For versions 3.15 and above the config parameter names have changed (refer to the previous sections of this document)

  • Aerospike node: Oracle VM on Vagrant box
  • Client: Oracle VM on Vagrant box
  • Operating System: Ubuntu 14.04
  • Aerospike Enterprise Edition: E-3.12.1.3
  • Aerospike C Client: C Client Library 4.1.3
  • Aerospike Java Client: Java Client Library 3.3.2
  • Aerospike cluster size: 3
  • Aerospike node IPs: 10.0.0.100, 10.0.0.103, 10.0.0.104
  • Client IP: 10.0.2.15
  • Number of Clients: 1
  • Cluster Name: aerocluster - cluster-name configuration parameter
  • TLS Name: cluster-name - tls-name configuration parameter
  • Root CA certificate: cacert.pem (When using a C Client)/ client.cert (When using a Java Client) - tls-cafile configuration parameter
  • Server certificate: cluster_chain.pem - tls-certfile configuration parameter
  • Key: key.pem - tls-keyfile configuration parameter

Prerequisites

Before configuring TLS in an Aerospike environment, ensure all prerequisites are complete.

Install Aerospike server Enterprise Edition version 3.11 or above. Set the heartbeat protocol to v3 across the cluster.

Set the cluster name

  1. Dynamically change the cluster name on the entire cluster using asadm:
Admin> asinfo -v 'set-config:context=service;cluster-name=aerocluster'
10.0.0.104:3000 (10.0.0.104) returned:
ok

vagrant-ubuntu-trusty-64:3000 (10.0.0.100) returned:
ok

10.0.0.103:3000 (10.0.0.103) returned:
ok
  1. Validate the cluster name change on each node:
Admin> show config like cluster-name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Service Configuration~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NODE        :   10.0.0.103:3000     10.0.0.104:3000     vagrant-ubuntu-trusty-64:3000   
cluster-name:   aerocluster         aerocluster         aerocluster             
  1. Check the stability of the cluster using asadm:
  • Check that there are no migrations pending, under the “Pending Migrations” column
  • Check that the size of the cluster is 3, under the “Cluster Size” column
Admin> info
~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Cluster         Node       […] Cluster […]  Cluster  […]  Uptime   
               Name          .         […]  Size   […] Integrity […]       .   
aerocluster           10.0.0.103:3000  […]     3   […] True      […] 14:12:12   
aerocluster           10.0.0.104:3000  […]     3   […] True      […] 14:11:11   
aerocluster           10.0.0.100:3000  […]     3   […] True      […] 08:35:35   
Number of rows: 3
~~~~~~~~~~~~~~Namespace Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace         Node    […]               Master              Replica […]       Pending      […]
        .          .      […] (Objects,Tombstones) (Objects,Tombstones) […]      Migrates      […]
        .          .      […]                    .                    . […]            (tx,rx) […]
bar       10.0.0.103:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.104:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.100:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar                       […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
test      10.0.0.103:3000 […] (45.515 K, 0.000  )  (45.502 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.104:3000 […] (43.278 K, 0.000  )  (43.613 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.100:3000 […] (44.069 K, 0.000  )  (43.747 K, 0.000  )  […] (0.000  , 0.000  ) […]
test                      […] (132.862 K, 0.000  ) (132.862 K, 0.000  ) […] (0.000  , 0.000  ) […]
Number of rows: 8
  1. Edit the Aerospike configuration file(aerospike.conf) on each node, to add the cluster-name in the service section. This ensures that the cluster-name doesn’t get reset upon the next restart of the Aerospike service.
service {
       ...
       cluster-name aerocluster
       ...
}

Configure the server nodes for TLS

Standard authentication

tls-certfile /home/user/cluster_chain.pem
tls-keyfile /home/user/key.pem

For version 3.15 and above the config parameters are renamed as below

cert-file /home/user/cluster_chain.pem
key-file /home/user/key.pem

Mutual authentication

tls-certfile /home/user/cluster_chain.pem
tls-keyfile /home/user/key.pem
tls-cafile /home/user/cacert.pem

For version 3.15 and above the config parameters are renamed as below.

cert-file /home/user/cluster_chain.pem
key-file /home/user/key.pem
ca-file /home/user/cacert.pem
  1. Copy the certificates to all the Aerospike nodes in the cluster

  2. Configure the nodes as described in the beginning of this document

  3. Restart the aerospike service on node 10.0.0.100:

vagrant@vagrant-ubuntu-trusty-64:~$ sudo service aerospike restart
 * Stopping aerospike                                                               [ OK ] 
 * Starting aerospike                                                               [ OK ] 
  1. Ensure the stability of the cluster using asadm:
  • Make sure the size of the cluster is correct. The info command within asadm shows the information about migrations and cluster size:
Admin> info
~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Cluster         Node       […] Cluster […]  Cluster  […]  Uptime   
               Name          .         […]  Size   […] Integrity […]       .   
aerocluster           10.0.0.103:3000  […]     3   […] True      […] 14:12:12   
aerocluster           10.0.0.104:3000  […]     3   […] True      […] 14:11:11   
aerocluster           10.0.0.100:3000  […]     3   […] True      […] 08:35:35   
Number of rows: 3
~~~~~~~~~~~~~~Namespace Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace         Node    […]               Master              Replica […]       Pending      […]
        .          .      […] (Objects,Tombstones) (Objects,Tombstones) […]      Migrates      […]
        .          .      […]                    .                    . […]            (tx,rx) […]
bar       10.0.0.103:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.104:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.100:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar                       […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
test      10.0.0.103:3000 […] (45.515 K, 0.000  )  (45.502 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.104:3000 […] (43.278 K, 0.000  )  (43.613 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.100:3000 […] (44.069 K, 0.000  )  (43.747 K, 0.000  )  […] (0.000  , 0.000  ) […]
test                      […] (132.862 K, 0.000  ) (132.862 K, 0.000  ) […] (0.000  , 0.000  ) […]
Number of rows: 8
  1. Restart the other 2 nodes one at a time.

  2. Connect to the TLS ports using asadm:

[vagrant@localhost ~]$ asadm -t aerocluster --tls_enable --tls_cafile /home/user/cacert.pem --tls_keyfile /home/user/key.pem --tls_certfile /home/user/cluster_chain.pem -h 10.0.0.100 -p 4333 --tls_protocols TLSv1.2
Aerospike Interactive Shell, version 0.1.15

Found 3 nodes
Online: 10.0.0.100:4333,10.0.0.103:4333,10.0.0.104:4333
  1. Run the C benchmark tool:

Standard Authentication

$ ./target/benchmarks -h "10.0.0.104:aerocluster:4333" --tlsEnable --tlsCaFile /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem
hosts:          10.0.0.104:aerocluster:4333
port:           3000
user:           (null)
namespace:      test
set:            testset
startKey:       1
keys/records:   1000000
bins:           1
object spec:    int
random values:  false
minimum number of transactions:  -1
workload:       read 50% write 50%
threads:        16
max throughput: unlimited
read timeout:   0 ms
write timeout:  0 ms
max retries:    1
debug:          false
latency:        false
shared memory:  false
read replica:   master
read consistency level: one
write commit level: all
asynchronous mode:  off
TLS:                    enabled
TLS encrypt only:       false
TLS cafile:             /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem
TLS capath:             (null)
TLS protocols:          (null)
TLS cipher suite:       (null)
TLS crl check:          false
TLS crl check all:      false
TLS cert blacklist:     (null)
TLS log session info:   false
TLS keyfile:            (null)
TLS certfile:           (null)
2017-09-19 17:28:21 INFO Add node BB9C8A831270008 10.0.0.104:4333
2017-09-19 17:28:21 INFO Add node BB9FAE279270008 10.0.0.103:4333
2017-09-19 17:28:21 INFO Add node BB910272D270008 10.0.0.100:4333
2017-09-19 17:28:21 INFO Read/write using 1000000 records
2017-09-19 17:28:21 INFO Start 16 generator threads
2017-09-19 17:28:22 INFO write(tps=3340 timeouts=0 errors=0) read(tps=3306 timeouts=0 errors=0) total(tps=6646 timeouts=0 errors=0)
2017-09-19 17:28:23 INFO write(tps=3136 timeouts=0 errors=0) read(tps=2969 timeouts=0 errors=0) total(tps=6105 timeouts=0 errors=0)
2017-09-19 17:28:24 INFO write(tps=3249 timeouts=0 errors=0) read(tps=3233 timeouts=0 errors=0) total(tps=6482 timeouts=0 errors=0)
2017-09-19 17:28:25 INFO write(tps=2984 timeouts=0 errors=0) read(tps=3037 timeouts=0 errors=0) total(tps=6021 timeouts=0 errors=0)
2017-09-19 17:28:26 INFO write(tps=3321 timeouts=0 errors=0) read(tps=3329 timeouts=0 errors=0) total(tps=6650 timeouts=0 errors=0)
2017-09-19 17:28:27 INFO write(tps=3101 timeouts=0 errors=0) read(tps=3085 timeouts=0 errors=0) total(tps=6186 timeouts=0 errors=0)
2017-09-19 17:28:28 INFO write(tps=3109 timeouts=0 errors=0) read(tps=3088 timeouts=0 errors=0) total(tps=6197 timeouts=0 errors=0)
2017-09-19 17:28:29 INFO write(tps=2857 timeouts=0 errors=0) read(tps=2938 timeouts=0 errors=0) total(tps=5795 timeouts=0 errors=0)
2017-09-19 17:28:30 INFO write(tps=3482 timeouts=0 errors=0) read(tps=3419 timeouts=0 errors=0) total(tps=6901 timeouts=0 errors=0)

Mutual Authentication

$ ./target/benchmarks -h "10.0.0.103:aerocluster:4333" --tlsEnable --tlsCaFile /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem --tlsCertFile /vagrant_data/test-master/x509_certificates/ca/subject/client_chain.pem --tlsKeyFile /vagrant_data/test-master/x509_certificates/ca/subject/Client/key.pem
hosts:          10.0.0.103:aerocluster:4333
port:           3000
user:           (null)
namespace:      test
set:            testset
startKey:       1
keys/records:   1000000
bins:           1
object spec:    int
random values:  false
minimum number of transactions:  -1
workload:       read 50% write 50%
threads:        16
max throughput: unlimited
read timeout:   0 ms
write timeout:  0 ms
max retries:    1
debug:          false
latency:        false
shared memory:  false
read replica:   master
read consistency level: one
write commit level: all
asynchronous mode:  off
TLS:                    enabled
TLS encrypt only:       false
TLS cafile:             /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem
TLS capath:             (null)
TLS protocols:          (null)
TLS cipher suite:       (null)
TLS crl check:          false
TLS crl check all:      false
TLS cert blacklist:     (null)
TLS log session info:   false
TLS keyfile:            /vagrant_data/test-master/x509_certificates/ca/subject/Client/key.pem
TLS certfile:           /vagrant_data/test-master/x509_certificates/ca/subject/client_chain.pem
2017-09-19 17:41:46 INFO Add node BB9FAE279270008 10.0.0.103:4333
2017-09-19 17:41:46 INFO Add node BB9C8A831270008 10.0.0.104:4333
2017-09-19 17:41:46 INFO Add node BB910272D270008 10.0.0.100:4333
2017-09-19 17:41:46 INFO Read/write using 1000000 records
2017-09-19 17:41:46 INFO Start 16 generator threads
2017-09-19 17:41:47 INFO write(tps=2713 timeouts=0 errors=0) read(tps=2716 timeouts=0 errors=0) total(tps=5429 timeouts=0 errors=0)
2017-09-19 17:41:48 INFO write(tps=3055 timeouts=0 errors=0) read(tps=2942 timeouts=0 errors=0) total(tps=5997 timeouts=0 errors=0)
2017-09-19 17:41:49 INFO write(tps=2998 timeouts=0 errors=0) read(tps=2966 timeouts=0 errors=0) total(tps=5964 timeouts=0 errors=0)
2017-09-19 17:41:50 INFO write(tps=3306 timeouts=0 errors=0) read(tps=3414 timeouts=0 errors=0) total(tps=6720 timeouts=0 errors=0)
2017-09-19 17:41:51 INFO write(tps=3027 timeouts=0 errors=0) read(tps=2990 timeouts=0 errors=0) total(tps=6017 timeouts=0 errors=0)
2017-09-19 17:41:52 INFO write(tps=2508 timeouts=0 errors=0) read(tps=2573 timeouts=0 errors=0) total(tps=5081 timeouts=0 errors=0)
  1. Run the Java benchmark tool:

Standard Authentication

$ java -Djavax.net.ssl.trustStore=/home/vagrant/trustStore -Djavax.net.ssl.trustStorePassword=123456 -jar target/aerospike-benchmarks-3.3.2-jar-with-dependencies.jar -h "10.0.0.100:aerocluster:4333" -tlsEnable
Benchmark: 10.0.0.100 4333, namespace: test, set: testset, threads: 16, workload: READ_UPDATE
read: 50% (all bins: 100%, single bin: 0%), write: 50% (all bins: 100%, single bin: 0%)
keys: 100000, start key: 0, transactions: 0, bins: 1, random values: false, throughput: unlimited
read policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, consistencyLevel: CONSISTENCY_ONE, replica: MASTER, reportNotFound: false
write policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, commitLevel: COMMIT_ALL
bin[0]: integer
debug: false
2017-09-19 17:53:55.664 INFO Thread 1 Add node BB910272D270008 10.0.0.100 4333
2017-09-19 17:53:55.786 INFO Thread 1 Add node BB9C8A831270008 10.0.0.104 4333
2017-09-19 17:53:55.787 INFO Thread 1 Add node BB9FAE279270008 10.0.0.103 4333
2017-09-19 17:53:55.903 write(tps=2 timeouts=0 errors=0) read(tps=0 timeouts=0 errors=0) total(tps=2 timeouts=0 errors=0)
2017-09-19 17:53:56.906 write(tps=1495 timeouts=0 errors=0) read(tps=1369 timeouts=0 errors=0) total(tps=2864 timeouts=0 errors=0)
2017-09-19 17:53:57.908 write(tps=2155 timeouts=0 errors=0) read(tps=2097 timeouts=0 errors=0) total(tps=4252 timeouts=0 errors=0)
2017-09-19 17:53:58.909 write(tps=2227 timeouts=0 errors=0) read(tps=2180 timeouts=0 errors=0) total(tps=4407 timeouts=0 errors=0)
2017-09-19 17:53:59.911 write(tps=2207 timeouts=0 errors=0) read(tps=2295 timeouts=0 errors=0) total(tps=4502 timeouts=0 errors=0)
2017-09-19 17:54:00.913 write(tps=2225 timeouts=0 errors=0) read(tps=2321 timeouts=0 errors=0) total(tps=4546 timeouts=0 errors=0)
2017-09-19 17:54:01.920 write(tps=1861 timeouts=0 errors=0) read(tps=1819 timeouts=0 errors=0) total(tps=3680 timeouts=0 errors=0)
2017-09-19 17:54:02.921 write(tps=2136 timeouts=0 errors=0) read(tps=2154 timeouts=0 errors=0) total(tps=4290 timeouts=0 errors=0)
2017-09-19 17:54:03.923 write(tps=1747 timeouts=0 errors=0) read(tps=1699 timeouts=0 errors=0) total(tps=3446 timeouts=0 errors=0)

Mutual Authentication

$ java -Djavax.net.ssl.trustStore=/home/vagrant/trustStore -Djavax.net.ssl.trustStorePassword=123456 -Djavax.net.ssl.keyStore=/home/vagrant/keyStore -Djavax.net.ssl.keyStorePassword=123456 -jar target/aerospike-benchmarks-3.3.2-jar-with-dependencies.jar -h "10.0.0.100:aerocluster:4333" -tlsEnable
Benchmark: 10.0.0.100 4333, namespace: test, set: testset, threads: 16, workload: READ_UPDATE
read: 50% (all bins: 100%, single bin: 0%), write: 50% (all bins: 100%, single bin: 0%)
keys: 100000, start key: 0, transactions: 0, bins: 1, random values: false, throughput: unlimited
read policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, consistencyLevel: CONSISTENCY_ONE, replica: MASTER, reportNotFound: false
write policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, commitLevel: COMMIT_ALL
bin[0]: integer
debug: false
2017-09-19 18:20:50.665 INFO Thread 1 Add node BB910272D270008 10.0.0.100 4333
2017-09-19 18:20:50.783 INFO Thread 1 Add node BB9C8A831270008 10.0.0.104 4333
2017-09-19 18:20:50.783 INFO Thread 1 Add node BB9FAE279270008 10.0.0.103 4333
2017-09-19 18:20:50.901 write(tps=1 timeouts=0 errors=0) read(tps=2 timeouts=0 errors=0) total(tps=3 timeouts=0 errors=0)
2017-09-19 18:20:51.903 write(tps=1510 timeouts=0 errors=0) read(tps=1499 timeouts=0 errors=0) total(tps=3009 timeouts=0 errors=0)
2017-09-19 18:20:52.904 write(tps=1947 timeouts=0 errors=0) read(tps=1840 timeouts=0 errors=0) total(tps=3787 timeouts=0 errors=0)
2017-09-19 18:20:53.905 write(tps=2183 timeouts=0 errors=0) read(tps=2253 timeouts=0 errors=0) total(tps=4436 timeouts=0 errors=0)
2017-09-19 18:20:54.907 write(tps=2278 timeouts=0 errors=0) read(tps=2160 timeouts=0 errors=0) total(tps=4438 timeouts=0 errors=0)
2017-09-19 18:20:55.908 write(tps=2229 timeouts=0 errors=0) read(tps=2226 timeouts=0 errors=0) total(tps=4455 timeouts=0 errors=0)