Add NAT support for redis cluster

[heri16]

Add support for redis clusters than are behind Network Address Translation (NAT).
This is useful for scenarios like this: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/accessing-elasticache.html#access-from-outside-aws

[jcstanaway]

This only works if natRemap contains the entire set of nodes in the cluster. In general, you don't need to specify all of the nodes in the nodeList argument when you do a new Redis.Cluster() and ioredis will dynamically learn the rest of the nodes in the cluster. This solution essentially requires the client to be fully configured with all of the nodes.

Further, this solution does not allow for the cluster to dynamically change.

1. The size of the cluster can not increase unless natRemap is originally set to include all possible nodes that may exist in the future.

2. The NAT mapping is static. If a node is ever restarted with a different IP address, the natRemap will need to be updated and the client restarted.

For rather static deployments, this appears to work, but the above limitations should be highlighted as this won't work in all deployments.

[heri16]

@ccs018 Yes, I am well aware of these limitations. ElastiCache ensures that both the DNS name and the IP address of the cache node remain the same when cache nodes are recovered in case of failure.
See here

Adding shards while online would require a RegEx-based implementation that maps all matching auto-generated internal-DNS hostnames to the Natted ip address. The node hostnames on AWS ElastiCache can be predicted ahead of time, and this is likely the same case for other automated deployment tools also. [xxxx-cache-0001-001.xxxx-cache.xx.xxxx1.cache.amazonaws.com] With the right regexp pattern, this addresses point 1 so that we can include all possible nodes that may exist in the future, including nodes spanning across availability zones.

To address point 2, the cluster should be using static internal hostnames instead of static internal ip addresses. This is already the case for AWS ElastiCache. If the node is ever restarted, internal dns should be updated to reflect the new IP address, without having to update natRemap or restarting the client.

Would we prefer a regex implementation? Alternatively, the configuration could be externalized to a JSON file with fs.watch() hot-reloading.

[heri16]

Just in case others are wondering why-NAT, this is to mitigate cold-start-times on AWS Lambda, in particular the slow performance when initializing new VPC-connection. This means an extra long time for ioredis to successfully connect to redis cluster because the VPC network interface requires some time to initialize and be ready.

See article

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 7 days if no further activity occurs, but feel free to re-open a closed issue if needed.

[luin]

Sorry for the (really) late response. This issue has been resolved in #758. Let me know if there's any problem.

[heri16]

Will look into it. Thanks!