Skip to main content
We are excited to be a part of AWS re:Invent 2024. Visit us at booth #1844 in Las Vegas.More info
Loading

Network Stanza Configuration

This page describes how to configure the service, fabric, and info sub-stanzas in the network stanza of the Aerospike configuration file,aerospike.conf.

Overview​

The network stanza of the Aerospike configuration file requires the following sub-stanzas:

  • service
  • fabric
  • info
  • heartbeat

To isolate fabric traffic (inter-node replication, migration) from heartbeat and service traffic, modify only the service and heartbeat sub-stanzas.

note

For information on how to configure the heartbeat stanza, see heartbeat sub-stanza which defines the interface for intra-cluster communications.

The service sub-stanza​

The following table describes each configuration item in the service sub-stanza.

Configuration itemDescription
addressInterfaces or IP addresses to bind and listen to. Multiple IP addresses are allowed.
access-addressInterfaces or IP addresses to publish for clients, typically clients within the same subnet or datacenter.
alternate-access-addressInterfaces 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-portWhen 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-portWhen 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.

Service sub-stanza configuration examples​

Example 1

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

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

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
}

Info and fabric sub-stanza configuration examples​

To isolate intra-cluster communication traffic from regular client traffic, specify the address in the fabric and info sub-stanzas. By default, they are set to any.

fabric {
  address any
  port 3001   # Intra-cluster communication port (migrates, replication, etc).
}

info {
  address any
  port 3003   # Plain text telnet management port.
}

To disable telnet access to the info port, comment out the info sub-stanza. If access control (security) is enabled, telnet access to the info port is automatically disabled.

More information​