4

Case Basics: Deployed a redis instance (single instance) in Google Cloud. Using NodeJS based server and redis-sentinel library to connect to the node. Reason being sentinel based management of nodes on google cloud.

I can login in the redis instance via dashboard/console's SSH login. Connect to the local running service of redis using redis-cli and can create/edit various datasets.

Issue: When i try to access it via my localhost or any other compute instance deployed within the same project domain. I am using public ip and port 26379/6379 for the connection but connection is being refused.

Possible reasons:

  • Network access policies.
Vikram Tiwari
  • 3,615
  • 1
  • 29
  • 39

3 Answers3

4

Struggled to set this up for myself last week, wanted to share the lessons I learnt here. Hope this is helpful, even if this is almost a year late :)

I was using a click-to-deploy scheme found here (Redis by Redis, not Bitnami), which allows an odd number of VMs to serve as a cluster.

Once the deployment is created, I had to perform the following manual steps on each VM to make it usable as a sentinel cluster:

  • redis-cli and run CONFIG SET protected-mode no and CONFIG REWRITE. This will expose the redis server to external connections.

  • sudo vi /etc/redis/sentinel.conf and add protected-mode no so sentinels can also connect to each other

  • sudo /etc/init.d/redis-sentinel start to start the sentinel service

  • redis-cli -p 26379 and check sentinel status by running sentinel ckquorum master. Expect to see 'OK X usable Sentinels', X being the number of VMs you have in the cluster.

Leftovers:

  • redis-sentinel DOES NOT run as a service. Need to be added to /etc/rc?.d alongside redis-server
  • /etc/init.d/redis-{server,sentinel} are not written as proper Debian services, hence they do not respawn once killed.

Overall very disappointed in this offering, was expecting a more finished setup.

Anton Drukh
  • 873
  • 7
  • 12
  • You don't just start/stop services in production, you restart the whole machine and the service should start upon reboot. I guess this is why you won't see "proper" service files. – Shay Erlichmen Oct 25 '16 at 13:09
  • Instead of having to vi into each machine, just `echo "protected-mode no" | sudo tee -a /etc/redis/sentinel.conf` – Roman Jun 30 '17 at 07:39
1

Usually, Google's click-to-deploy services DO NOT automatically add network/firewall rules & policies - you will have to do that yourself.

Obviously, you should take care when opening the port to only allow access from your Compute Engine network.

Tom
  • 1,563
  • 12
  • 12
  • I deploy a redis cluster using click to deploy. It create three vm there. Now when i connect to one instance from node js it works. But when i try to connect it as cluster it throw a error [Error: Failed to refresh slots cache.] https://github.com/luin/ioredis#cluster I have also try sentinel code https://github.com/luin/ioredis#sentinel My vms http://prntscr.com/860m65 – Max Aug 18 '15 at 12:46
0

When you start on Google Cloud, they keep your whole infrastructure in a private cloud (even if across regions), which gets assigned private IPs unless you launch instances which require to talk to external cloud and thus need Ephemeral IP. All the instances in the private cloud are allowed access of each other, using private IPs. This is by default set in the firewall rules of the system, so you don't need to set them.

Best practice would be to provide a singular node point for your public access of GUI/API and bind the rest via internal IPs. Saves time, reduces latency and secure in private cloud.

The issue in my case was certainly firewall rule as specified by @Tom. You can modify policies to allow connections. But i would recommend anyone to use internal IPs for connections among different instances.

Vikram Tiwari
  • 3,615
  • 1
  • 29
  • 39