Network configuration
This page describes how to configure critical network ports on an Aerospike Database.
Aerospike Database’s network configuration stanza sets up critical network ports to be used by other nodes, application, and tools. The following table describes the ports used by Aerospike Database and Cross datacenter replication (XDR).
Name | Default port | Description |
---|---|---|
service | 3000 | Application, tools, and remote XDR use the service port for database operations and cluster state. |
fabric | 3001 | Intra-cluster communication port. Replica writes, migrations, and other node-to-node communications use the fabric port. |
mesh heartbeat | 3002 | Heartbeat protocol ports form and maintain the cluster. Only one heartbeat port may be configured. Mesh heartbeat and fabric should run on the same NIC. |
multicast heartbeat | 9918 | Heartbeat protocol ports are used to form and maintain the cluster. Only one heartbeat port may be configured. |
admin | 3003 | A dedicated admin port for continuous access by the monitoring stack exporter, as well as emergency access to unresponsive nodes using asadm and asinfo . |
Verify that all application and XDR nodes can communicate to the service port on all Aerospike nodes, and that each node can communicate over the configured heartbeat and fabric ports.
Configure network sub-stanzas
The network stanza of the Aerospike configuration file requires the following sub-stanzas:
- service
- fabric
- heartbeat
- admin
To isolate fabric (inter-node replication, migration) and heartbeat from service traffic or XDR traffic, add an address distinct from the service address to the heartbeat and fabric sub-stanzas.
The service sub-stanza
The following table describes each configuration item in the service sub-stanza.
Configuration item | Description |
---|---|
address | Interfaces or IP addresses to bind and listen to. Multiple IP addresses are allowed. |
access-address | Interfaces or IP addresses to publish for clients, typically clients within the same subnet or datacenter. |
alternate-access-address | Interfaces or IP addresses to publish for clients that can’t connect to access-address interfaces or IP addresses. If the items specified here are actual interfaces and not mapped over NAT, then the corresponding address configuration must be specified unless address any is set. Clients requiring the alternate-access-address to be returned must request it by specifying useServicesAlternate in their client policy. |
access-port | When configured, this port is published to the clients. Requires port forwarding to be set up when the value is different than the port . |
alternate-access-port | When configured and the client specifies useServicesAlternate in the client policy, this port is published to the clients. Requires port forwarding to be set up when the value is different than the port . |
Example 1: Service sub-stanza configuration
Host with 2 network interfaces, x.x.x.x and y.y.y.y, with x.x.x.x for clients within the same subnet/DC (private IP) and y.y.y.y for clients in a different subnet/DC (public IP). The IP address y.y.y.y is not mapped over NAT:
service { address x.x.x.x address y.y.y.y access-address x.x.x.x alternate-access-address y.y.y.y}
The access-address
x.x.x.x prevents the y.y.y.y IP to also be broadcast. If access-address
is not specified, all IPs specified as address
are published or broadcast.
Example 2: Service sub-stanza configuration
If the y.y.y.y IP is mapped over NAT:
service { address x.x.x.x access-address x.x.x.x alternate-access-address y.y.y.y}
Or, as address
is published by default when not overwritten through access-address
:
service { address x.x.x.x alternate-access-address y.y.y.y}
Example 3: Service sub-stanza configuration
This alternate configuration works in most cases: leaving address any
empty binds to all available interfaces, then publishes the specific access-address
and alternate-access-address
.
service { address any access-address x.x.x.x alternate-access-address y.y.y.y}
Fabric sub-stanza configuration examples
To isolate intra-cluster communication traffic from regular client traffic, specify an address different from the service sub-stanza for the fabric and heartbeat sub-stanzas. By default, they are set to any
.
fabric { address any port 3001 # Intra-cluster communication port (migrates, replication, etc).}
Admin sub-stanza
The following table describes each configuration item in the optional admin sub-stanza.
Parameter | Description |
---|---|
port | Port that is not secured (non-TLS) at which the server listens for admin client connections. |
address | IP address at which the server listens (binds) for non secured (non-TLS) admin connections. |
tls-authenticate-client false : Only client authenticating the server.any : Two way (mutual) authentication, both client and server need to be authenticateduser-defined: Two way (mutual) authentication along with subject validation. | |
tls-port | TLS-enabled port where the server listens for admin client connections. |
tls-name | Specifies which TLS parameters to use for the given context TLS connections. |
tls-address | IP address where the server listens (binds) for secured (TLS) admin connections. |
disable-localhost | When set to true , the service will not listen on localhost. |
Example configuration:
network { admin { port 3003 address any tls-port 3004 tls-name asd_node tls-address any tls-authenticate-client any disable-localhost false }}
You can use the admin port to remove an unresponsive node. See Ejecting an unresponsive node using asadm and the admin port.
More information
- Configure the heartbeat sub-stanza.
- Configure Rack awareness to enable Aerospike to support top-of-rack switch failure.
- Configure Aerospike Database.