Network

This page describes network planning requirements: ports, topology, and throughput limits. For configuration steps after planning, see Network configuration.

Deploy Aerospike clients and servers in a secure network, such as a VPN, and block unknown clients from Aerospike TCP ports before you tune performance.

Aerospike network usage

• All connections are made through standard TCP, transporting Aerospike developed wire-protocol.
• Heartbeat signals can be sent in multicast mode, or mesh mode (node-to-node using TCP).
• Typical ports that are open:
  • 3000 - service port, which handles client requests and responses.
  • 3001 - fabric port, which handles server node-to-node communication.
  • 3002 - heartbeat port, which is optionally used for heartbeat TCP messages.
  • 3003 - admin port, which provides a dedicated path for administration commands.
  • 3004 - TLS-enabled admin port, if configured.
• Aerospike does not require specialized network equipment or drivers.
• Aerospike supports both 1 Gb and 10 Gb interfaces.
• Working with record sizes larger than the MTU can impact write latency. The default MTU is 1500. See Write transaction analysis for more information.

Network topology requirements

• To ensure the integrity and protection of data, Aerospike client and server nodes must be deployed within a secure network environment such as a VPN. Do not allow unknown clients to connect to the Aerospike TCP ports.
• To ensure performance, minimize intermediate network devices such as routers or multiple switches between client and server nodes.
• Server nodes are recommended to be physically as close as possible with minimal ping time, so a tightly coupled stable cluster can be maintained.
• See TLS Configuration for details on setting up TLS.

Other recommendations

• With default settings, a node typically supports up to 100K TPS, which is sufficient for most use cases. For higher throughput:
  • In most cases, system interrupts limit TPS more than bandwidth does. By using the top command and pressing 1, you can see how the CPU cores are spending their time. A high value in the si column for any core may indicate sharing of a single interrupt on the Ethernet port. If you have multiple interrupts available, you can spread the interrupts to different cores. Check with the manufacturers of your network cards to see if they allow for multiple interrupts. See SMP affinity documentation to learn about balancing interrupts across cores.
  • If you have multiple 1 Gb Ethernet ports, you can use link aggregation to bond them and increase throughput. The method to configure link aggregation varies according to your hardware. See IEEE 802.3ad link aggregation to learn more. Aerospike customers have aggregated four 1 Gb ports into a single 4 Gb connection. No Aerospike configuration changes are necessary.
  • If a 10 Gb Ethernet port is available, use it instead of link aggregation to bond multiple 1 Gb ports. No Aerospike configuration changes are necessary.
• When multiple Ethernet ports are available, you can direct service traffic (web and application servers) to one port and intra-cluster communications to another. While not a requirement, this is the network architecture for which Aerospike was intended. If a node fails, data is transferred from one server to another. By separating service traffic from intra-cluster traffic, you can increase reliability for the service traffic. See multiple NIC configuration on AWS to learn more.
• We do not recommend using third-party load balancers between web and application servers and your Aerospike cluster. Aerospike handles load balancing itself.
• There are sometimes controls in place to detect denial-of-service attacks, such as Storm Control. Because the way that applications access Aerospike, these may look like attacks, resulting in a degradation or shutdown of service. It is highly recommended to turn off Storm Control.