--- title: "Aerospike on Amazon EC2 - IP Addressing" description: "Configure Aerospike IP addressing on AWS EC2, including Elastic IPs (EIPs), multiple network interface cards (NICs), and XDR networking." --- # Aerospike on Amazon EC2 - IP Addressing > For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt) > > All documentation pages available in markdown. This page describes IP addressing for Aerospike Database on Amazon EC2, including private IP addresses, public IP addresses, Elastic IP (EIP) addresses, mesh heartbeat, XDR networking, and binding traffic to multiple network interface cards (NICs) through Elastic Network Interfaces (ENIs). ## IP addressing on EC2-VPC platform On the EC2-VPC platform, you can use private IP addresses, public IP addresses, and EIP addresses. Use the following guidelines to configure your choice of IP address for Aerospike on AWS. - Private IP address: Aerospike clients can access a cluster using the AWS private IP address. A private IP address cannot be reached from the internet. - EIP address: A static public IP address that remains associated with an instance even when the instance is stopped and restarted. - A public IP address: Can be reached from the internet and is assigned to default-VPC instances by default. Non-default-VPC instances, however, must have public IP address assignment enabled. Public IP addresses are disassociated from an instance when it is stopped or an ENI or EIP is added to the instance. ## Configure a private IP address Configure the Aerospike server so that Aerospike clients can access a cluster using the AWS private IP address. EC2-VPC instances receive a static private IP address from the range of your VPC addresses by default. 1. In `aerospike.conf`, verify the following network configuration. ```plaintext network { service { address any port 3000 } } ``` 2. Start the Aerospike server. ```plaintext sudo service aerospike restart ``` ## Configure a public IP or EIP Configure public IP addresses and EIPs when Aerospike clients access the cluster from a public network. Use the following steps on each node in the cluster. 1. Edit `/etc/aerospike/aerospike.conf`. 2. Add `access-address` with the EIP of the node under `network.service`. 54.208.32.99 is the example EIP in the following configuration. ```plaintext network { service { address any port 3000 access-address 54.208.32.99 virtual } } ``` 3. Restart the Aerospike server. ```plaintext sudo service aerospike restart ``` ### Seed node as a proxy Because an AWS instance can have both a public and private IP address for an ENI, database commands may be forwarded through the seed node as a proxy. For example, assume we have a cluster of three servers. The servers are all part of the same AWS VPC. The addresses for each of the servers are as follows: | Node | Internal IP Address | Public IP Address | | --- | --- | --- | | Server\_1 | 172.18.10.76 | 52.91.243.125 | | Server\_2 | 172.18.10.82 | 52.105.13.44 | | Server\_3 | 172.18.10.26 | 54.91.34.242 | Run `ifconfig` on the EC2 instance to display only the private IP addresses. The public IP address is mapped to the private IP address through network address translation (NAT) and is not part of the server configuration. ```plaintext ifconfig ``` Sample output: ```text eth0 Link encap:Ethernet HWaddr 12:5A:18:B8:AD:15 inet addr:172.18.10.76 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::105a:18ff:feb8:ad15/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:809 errors:0 dropped:0 overruns:0 frame:0 TX packets:515 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:534945 (522.4 KiB) TX bytes:52512 (5 a.2 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:140 (140.0 b) TX bytes:140 (140.0 b) ``` You can find the public IP of your instance on the EC2 Dashboard, or by running the `aws` command on your instance. ```plaintext aws ec2 describe-instances ``` Sample output: ```text "NetworkInterfaceId": "eni-b51f0394", "PrivateIpAddresses": [ { "PrivateDnsName": "ip-172-18-10-76.ec2.internal", "Association": { "PublicIp": "52.91.243.125", "PublicDnsName": "ec2-52-91-243-125.compute.amazonaws.com", "IpOwnerId": "amazon" }, "Primary": true, "PrivateIpAddress": "172.18.10.76" } ] ``` ### Client connection to seed node When the Aerospike client connects to a seed node in the cluster through its public IP address, it receives the internal IP addresses for all the other nodes in the cluster. The client attempts to add each of the nodes with the internal IP addresses. The client receives a timeout for the nodes other than the seed node. The following sample output shows a client request timeout. Sample output: ```text 2015-11-03 17:55:53.055 INFO Thread 1 Add node BB9A1541F839E12 54.172.74.76:3000 2015-11-03 17:55:54.322 WARN Thread 1 Add node 172.18.10.82:3000 failed: Error Code 11: java.net.SocketTimeoutException: connect timed out 2015-11-03 17:55:55.324 WARN Thread 1 Add node 172.18.10.26:3000 failed: Error Code 11: java.net.SocketTimeoutException: connect timed out ``` All database commands succeed at this point because the client uses the seed node as a proxy for the other nodes. However, the performance will be poor because all the commands will be sent through the seed node as the proxy. ### Timeout errors Following are the timeout errors when the client attempts to connect to one of the private IP addresses. Sample output: ```text 2015-11-03 17:55:56.417 WARN Thread 8 Add node 172.18.10.82:3000 failed: Error Code 11: java.net.SocketTimeoutException: connect timed out 2015-11-03 17:55:56.442 write (tps=12 timeouts=0 errors=0) read(tps=62 timeouts=0 errors=0) total(tps=74 timeouts=0 errors=0) 2015-11-03 17:55:57.418 WARN Thread 8 Add node 172.18.10.26:3000 failed: Error Code 11: java.net.SocketTimeoutException: connect timed out ``` The client continues to try and add the nodes with internal IP addresses and receive timeouts. Even though commands succeed, the timeouts are a sign that there may be a network problem. #### Search the log file You can search into the Aerospike log file (`/var/log/aerospike/aerospike.log`) to confirm that there are commands being proxied to the nodes with internal IP addresses. Terminal window ```bash grep " proxy (" /var/log/aerospike/aerospike.log ``` Sample output: ```text INFO (info): (ticker.c:587) {test} client: tsvc (0,0) proxy (3251,0,0) read (...) write (...) delete (...) udf (...) lang (...) ``` The `proxy` tuple in the `client` ticker line reports proxied client transactions as `(complete,error,timeout)`. Under normal conditions, except during migrations, the tuple should be `proxy (0,0,0)`. In the sample output, the seed node has completed 3251 proxied client transactions. If a client or monitoring tool connects through a public IP and receives private IP addresses for peer nodes, it may only reach the seed node. Run the `info` command with the [`asadm`](https://aerospike.com/docs/database/tools/asadm) tool on one node to confirm whether all nodes are visible from inside the cluster. ### Correct client/IP address problems Add the `access-address` parameter to the network configuration of the `aerospike.conf` file to correct the problem of an external Aerospike client using internal IP addresses. ```plaintext network { service { address any port 3000 access-address 54.208.32.99 virtual } } ``` When you use the `access-address` parameter, the database verifies that the address is valid for one of the network ports. If it is not a valid IP address for a network port, then the database will not start. Example log output: ```text Nov 04 2015 01:15:31 GMT: INFO (cf:misc): (id.c::119) Node ip: 172.18.10.26 Nov 04 2015 01:15:31 GMT: INFO (cf:misc): (id.c::327) Heartbeat address for mesh: 172.18.10.26 Nov 04 2015 01:15:31 GMT: INFO (config): (cfg.c::3231) Rack Aware mode not enabled Nov 04 2015 01:15:31 GMT: INFO (config): (cfg.c::3234) Node id bb96f7dbef24f12 Nov 04 2015 01:15:31 GMT: CRITICAL (config): (cfg.c:3265) external address '54.208.32.99' does not match service addresses '172.18.10.26:3000' Nov 04 2015 01:15:31 GMT: WARNING (as): (signal.c::135) SIGINT received, shutting down Nov 04 2015 01:15:31 GMT: WARNING (as): (signal.c::138) startup was all not complete, exiting immediately ``` The additional keyword `virtual` must be added to the end of the `access-address` line in the configuration file so that the database starts properly. With the `access-address` parameter set with the keyword `virtual` the Aerospike client using public IPs will be able to communicate with all of the nodes in the cluster. Because commands will no longer be proxied through the seed node, the performance will be significantly better. ## Multiple virtual network interfaces Each NIC on an Amazon Linux Hardware Virtual Machine (HVM) instance can handle about 250K packets per second, which can bottleneck on cores processing interrupts. Additional ENIs can process more packets per second on the same instance. If you need higher performance per instance, you can add multiple ENIs to an instance. For binding client, XDR, heartbeat, and fabric traffic to separate NICs, see [Multiple NICs](#multiple-nics). ::: note Using ENIs with private IPs is free of cost in AWS. ::: ### Multiple ENIs with one interface If the instance contains multiple ENIs, configure `access-address` under `network.service` with the address of the NIC that provides access to the node. 1. For each node in the cluster, use `ifconfig` to list the interfaces and IP addresses. ```plaintext ifconfig -a ``` Sample output: ```text eth0 Link encap:Ethernet HWaddr 12:CC:47:86:8F:AF inet addr:172.18.10.189 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::10cc:47ff:fe86:8faf/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:832 errors:0 dropped:0 overruns:0 frame:0 TX packets:694 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:98191 (95.8 KiB) TX bytes:81771 (79.8 KiB) eth1 Link encap:Ethernet HWaddr 12:DF:E3:5B:FB:69 inet addr:172.18.224.190 Bcast:172.18.10.255 Mask:255.255.255.0 inet6 addr: fe80::10df:e3ff:fe5b:fb69/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:716 (716.0 b) TX bytes:1206 (a.1 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:140 (140.0 b) TX bytes:140 (140.0 b) ``` 2. Edit `/etc/aerospike/aerospike.conf` and add the `access-address` line under `network.service` with the private IP address of the selected interface. In the following example, the IP address for eth1 is used. ```plaintext network { service { address any port 3000 access-address 172.18.224.190 } } ``` 3. Restart the Aerospike server. ```plaintext sudo service aerospike restart ``` 4. Confirm `access-address` after the server restarts. ```plaintext asinfo -v services 172.18.224.189:3000,172.18.224.194:3000,172.18.224.195:3000 ``` 5. Verify the access-address of the other nodes in the cluster. ```plaintext asinfo -v services 172.18.224.189:3000,172.18.224.194:3000,172.18.224.195:3000 ``` ## Multiple NICs The following sections describe how to add and modify multiple NICs to improve Aerospike network performance by separating different types of traffic by their respective ports, and binding that traffic to a specific NIC. This is supported in heartbeat protocol v3. The goal is to isolate client traffic from XDR traffic using different NICs over port 3000, and also separate mesh heartbeat traffic over port 3002 and fabric network traffic over port 3001. Each of these network traffic types use a specific NIC on the instance. ### Network traffic isolation The following table assumes four NICs per node, and two clusters A and B. - NICs in nodes on cluster A labeled A\_eth{0-3} - NICs in nodes on cluster B labeled B\_eth{0-3} **Traffic Isolation Table** | NIC | Setting | Traffic type | Port | | --- | --- | --- | --- | | A\_eth0 | access-address | client | 3000 | | A\_eth1 | alternate-access-address | XDR | 3000 | | A\_eth2 | heartbeat > address | Heartbeat | 3002 | | A\_eth3 | fabric > address | Fabric | 3001 | | B\_eth0 | access-address | Client | 3000 | | B\_eth1 | alternate-access-address | XDR | 3000 | | B\_eth2 | heartbeat > address | Heartbeat | 3002 | | B\_eth3 | fabric > address | Fabric | 3001 | ### Add a NIC on a running cluster 1. Check current NIC stats on the EC2 instance. From the command line or the AWS Console: ```plaintext ifconfig ``` Sample output: ```text eth0 Link encap:Ethernet HWaddr 0E:F9:00:58:88:62 inet addr:10.0.0.182 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::cf9:ff:fe58:8862/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:56729 errors:0 dropped:0 overruns:0 frame:0 TX packets:44089 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:25110351 (23.9 MiB) TX bytes:5487096 (5.2 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:217 errors:0 dropped:0 overruns:0 frame:0 TX packets:217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:44332 (43.2 KiB) TX bytes:44332 (43.2 KiB) ``` 2. Retrieve the instance metadata. ```plaintext curl http://169.254.169.254/latest/dynamic/instance-identity/document { "devpayProductCodes" : null, "privateIp" : "10.0.0.182", "availabilityZone" : "us-east-1a", "version" : "2010-08-31", "region" : "us-east-1", "instanceId" : "i-074831c705d8eb129", "billingProducts" : null, "instanceType" : "c4.xlarge", "accountId" : "268841430234", "architecture" : "x86_64", "kernelId" : null, "ramdiskId" : null, "imageId" : "ami-b239daa4", "pendingTime" : "2017-01-23T23:33:05Z" } ``` 3. Retrieve the security group. ```plaintext curl http://169.254.169.254/latest/meta-data/security-groups AWSMPMyVPCCluster-71H99AZ60CK6 ``` 4. Create new ENI. a. On the AWS console, click NETWORK & SECURITY → Network Interfaces. b. Click `Create Network Interface`. c. Select the availability-zone that matches the one your instance is using. d. Select the security group for your network. e. Click `Yes Create` f. Select the newly created Network Interface and click Attach. g. Select `InstanceID` for your running instance and click Attach. Create other ENIs as needed, to match the traffic isolation table above. 5. Create XDR-dedicated NIC. a. On the AWS console, click NETWORK & SECURITY → Elastic IPs. b. Click `Allocate new address`. c. Click `Allocate` and note the address of the new EIP. d. Select the new EIP, and then click `Associate Address`. e. Select Resource Type \[Network interface\], choose the ENI for the eth1 NIC of the instance, and its IP as the private IP. Repeat with the other nodes of the cluster. 6. Verify new NICs. ```plaintext ifconfig ``` Sample output: ```text eth0 Link encap:Ethernet HWaddr 0E:F9:00:58:88:62 inet addr:10.0.0.182 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::cf9:ff:fe58:8862/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:57474 errors:0 dropped:0 overruns:0 frame:0 TX packets:44785 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:25312145 (24.1 MiB) TX bytes:5579362 (5.3 MiB) eth1 Link encap:Ethernet HWaddr 0E:0A:CC:FB:AD:8A inet addr:10.0.0.29 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::c0a:ccff:fefb:ad8a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:27 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1128 (a.1 KiB) TX bytes:2766 (2.7 KiB) eth2 Link encap:Ethernet HWaddr 0E:53:3F:CD:BB:02 inet addr:10.0.0.210 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::c53:3fff:fecd:bb02/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:830 (830.0 b) TX bytes:2214 (2.1 KiB) eth3 Link encap:Ethernet HWaddr 0E:82:D3:7D:D4:BE inet addr:10.0.0.87 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::c82:d3ff:fe7d:d4be/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:17 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:768 (768.0 b) TX bytes:2058 (2.0 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:217 errors:0 dropped:0 overruns:0 frame:0 TX packets:217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:44332 (43.2 KiB) TX bytes:44332 (43.2 KiB) ``` 7. Verify IP addresses. ```plaintext netstat -anpt ``` Sample output: ```text (No info could be read for "-p": geteuid()=500 but you should be root.) Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:3003 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:36300 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN - tcp 0 0 10.0.0.182:44996 10.0.0.112:3001 ESTABLISHED - tcp 0 1016 10.0.0.182:22 204.153.194.234:32501 ESTABLISHED - tcp 0 0 10.0.0.182:3002 10.0.0.112:46318 ESTABLISHED - tcp 0 0 10.0.0.182:3001 10.0.0.112:57388 ESTABLISHED - tcp 0 0 10.0.0.182:3001 10.0.0.112:57390 ESTABLISHED - tcp 0 0 :::22 :::* LISTEN - tcp 0 0 :::34438 :::* LISTEN - tcp 0 0 :::111 :::* LISTEN - ``` 8. Verify IP address broadcast to Aerospike clients. ```plaintext asinfo -v service 10.0.0.182:3000 asinfo -v services 10.0.0.112:3000 asinfo -v services-alternate 34.197.64.209:3000 ``` 9. Modify `aerospike.conf` for multiple NICs. In `aerospike.conf`, add or modify the `access-address` and `alternate-access-address` parameters under `network.service`, and set `address` under `network.heartbeat` and `network.fabric`: ```plaintext network { service { address any # listen on any available interface for service traffic port 3000 access-address 10.0.0.182 # eth0 for service calls alternate-access-address 34.197.253.11 # eth1 EIP value for XDR } heartbeat { mode mesh protocol v3 # required for using separate NICs for mesh heartbeat and fabric address 10.0.0.210 # eth2 for mesh heartbeat port 3002 mesh-seed-address-port 10.0.0.210 3002 # eth2 of this node mesh-seed-address-port 10.0.0.246 3002 # eth2 on node B interval 150 # number of milliseconds between heartbeats timeout 15 # number of heartbeats failing in a row before timing out } fabric { address 10.0.0.87 # eth3 for fabric communication port 3001 } admin { address any port 3003 } } ``` After you bind service, XDR, heartbeat, and fabric traffic to separate NICs, configure mesh heartbeat separately as described below. ## Aerospike heartbeat on AWS AWS does not allow multicast addressing. The default configuration for the heartbeat mode must be modified from multicast mode to mesh mode. Then, the port and the `mesh-seed-address-port` settings must be set. The port should be changed to the port used for the heartbeat. The mesh-seed address-port-setting should be set to the IP address and heartbeat port of a node in the cluster. It is a good idea to have more than one mesh seed node because if a seed node goes offline, a client may not be able to contact the cluster. In the current versions of Aerospike Database (heartbeat-protocol=v3), you cannot configure the heartbeat to use a public IP or EIP address because the node does not have any interface that binds that IP; the public IP is made available using NAT in the EC2 infrastructure, so the node does not see it directly. For information about how to configure the network heartbeat, see [Network Heartbeat Configuration](https://aerospike.com/docs/database/8.1.2/manage/network/heartbeat). ## Aerospike XDR IP addresses on AWS This section describes how to configure Aerospike XDR networking with locally accessible IP addresses on AWS, or with public and EIP addresses on AWS using the `access-address` configuration. ### XDR with locally-accessible IP Addresses on AWS 1. For each node edit `/etc/aerospike/aerospike.conf`. 2. In the `xdr` configuration, under `datacenter`, set `dc-node-address-port` to the local IP address of one node in the remote cluster. ```plaintext xdr { # http://www.aerospike.com/docs/database/manage/xdr/static-xdr enable-xdr true # Globally enable/disable XDR on local node. namedpipe-path /tmp/xdr_pipe # XDR to/from Aerospike communications channel. digestlog-path /opt/aerospike/digestlog 100G # Track digests to be shipped. errorlog-path /var/log/aerospike/asxdr.log # Log XDR errors. xdr-pidfile /var/run/aerospike/asxdr.pid # XDR PID file location. local-node-port 3000 # Port on local node used to read records etc. info-port 3004 # Port used by tools to monitor XDR health, current config, etc. xdr-compression-threshold 1000 # http://www.aerospike.com/docs/database/manage/xdr/static-xdr # Canonical name of the remote datacenter. datacenter REMOTE_DC_1 { dc-node-address-port 172.18.224.189 3000 } } ``` 3. Restart the Aerospike server. ```plaintext sudo service aerospike restart ``` ### Configure access-address The following example demonstrates how to configure `access-address` to set up communications for XDR. This configuration is most appropriate when neither cluster can communicate over a private network, and the Aerospike clients access the clusters over the public network. This configuration introduces a second VPC that places the clusters on separate networks. The local address for each remote node should have a `dc-node-address-port` entry in `aerospike.conf`. After all the nodes have been added, each local address is mapped with a `dc-int-ext-ipmap` line under `xdr.datacenter` in `aerospike.conf`. With the IP addresses mapped on the local cluster and `access-address` set to the external addresses on the remote cluster, XDR can begin replication between the two clusters. The following table shows the public and private IP addresses for the example. | Cluster | AZ | VPC | Internal IP | Ext IP | | --- | --- | --- | --- | --- | | Local | us-east-1a | VPC1 | 172.18.10.18 | 54.175.209.97 | | Local | us-east-1a | VPC1 | 172.18.10.190 | 54.164.210.61 | | Remote | us-east-1b | VPC2 | 10.2.0.15 | 52.90.223.53 | | Remote | us-east-1b | VCP2 | 10.2.0.201 | 52.23.170.121 | 1. For each node edit `/etc/aerospike/aerospike.conf`. 2. Configure `access-address` on each node in the remote cluster using the EIP and the keyword “virtual”. ```plaintext xdr { # http://www.aerospike.com/docs/database/manage/xdr/static-xdr enable-xdr true # Globally enable/disable XDR on local node. namedpipe-path /tmp/xdr_pipe # XDR to/from Aerospike communications channel. digestlog-path /opt/aerospike/digestlog 100G # Track digests to be shipped. errorlog-path /var/log/aerospike/asxdr.log # Log XDR errors. xdr-pidfile /var/run/aerospike/asxdr.pid # XDR PID file location. local-node-port 3000 # Port on local node used to read records etc. info-port 3004 # Port used by tools to monitor XDR health, current config, etc. xdr-compression-threshold 1000 # http://www.aerospike.com/docs/database/manage/xdr/static-xdr # Canonical name of the remote datacenter. datacenter REMOTE_DC_1 { dc-node-address-port 10.2.0.154 3000 dc-node-address-port 10.2.0.201 3000 # Remote nodes' internal-to-external ip map - include all remote nodes. # These are needed only when there are multiple NICs. dc-int-ext-ipmap 10.2.0.154 52.90.223.53 dc-int-ext-ipmap 10.2.0.201 52.23.170.121 } } ``` 3. Restart the Aerospike server. ```plaintext sudo service aerospike restart ```