Re: [consul] Moving service to another host correctly

[Armon Dadgar]

Hey,

To clarify, Consul is modeling services that exists on the current node, so unless the

application itself is literally migrating, it doesn’t make sense to move the service registration.

Consul services are associated with the node running that service, so if you start your application

on a new node, you would register with the local Consul agent to indicate that your service is

running.

Does that clarify?

Best Regards,

Armon Dadgar

From: S Dv <srv.d...@gmail.com>
Reply: consu...@googlegroups.com <consu...@googlegroups.com>>
Date: November 23, 2015 at 2:16:14 AM
To: Consul <consu...@googlegroups.com>>
Subject:  [consul] Moving service to another host correctly

Hello,

I'm facing the following with implementing failover.
I will simplify our infrastructure up to 2 nodes (all services have some related checks). All services are up and used by applications.

Node1:
   master-service-A
   master-service-B

Node2:
   slave-service-A
   slave-service-B

Let say at some time the service "master-service-A" will crash and have to move it to Node2 but on the other hand I do not want to move service B on Node2.
I didn't find any option to migrate a single service from node using HTTP API. I found only the way to deregister and register once again node with different name but I'm trying to build service oriented infrastructure rather than node oriented.

On the other hand I can't "just move service" using curl to move service + related checks to another node.

curl -X PUT -d '{"Node": "node2", "Address": "new_api", "ServiceId": "master-service-A"}' http://localhost:8500/v1/catalog/register

Any thoughts or suggestions?

thanks in advance

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
IRC: #consul on Freenode
---
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/f9a8c0d8-29cf-481a-a8ec-51820da56502%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[S Dv]

Thanks for your reply.

I was speaking about a little bit different thing. I'm not moving application nor adding new nodes. Let me add a bit more details.

I have 3 client nodes (and a couple of server nodes):

- APP node (with application)

- Node1 node (with two services: pg-master-db, redis-db)

- Node2  (with two services: pg-slave-db, redis-db)

Node2 in terms of databases is a replication of master database (node1). Application queries master and slave and both redis nodes. Once pg-master-db goes down (not the whole host but only the one service) I'd would like to make a failover and get the next structure

- APP node

- Node1 (with redis-db)

- Node2 (with pg-slave-db, pg-master-db, redis-db).

As for now I'm considering to do the following during failover:

- deregister current service pg-master-db from Node1

- change a k/v pair in consul to provide new host for a master: curl -x put -d "node2" http://....../pg/master-db

- on each slave introduce consul's watcher to watch for the key pg/master-db (during setup)

- script used in watcher compares new value from with host name and will register another service from local template and call it pg-master-db (the rest of slave do nothing).

It's a little bit complex approach and it would be great if I can just update the pg-master-db declaration and "move it" on node2 but it seems to be impossible.

So.. are there any more simple ways to perform such failover?

thanks

[Armon Dadgar]

Hey,

I think I understand much better now. The easier way to do this is have both machines

provide the “pg-db” service, and then tag them with either “slave” or “master” as appropriate.

With Consul 0.6 you can use the “enableTagOverride” feature which allows the services to

change the tag value on the clients. This way, your coordinator can remove the “master” tag

from one instance and apply it to another instance using the catalog APIs.

You can use consul-template or watchers to then just watch for “master.pg-db.service” just

like normal, instead of adding a KV interaction.

Hope that helps!

[S Dv]

Works for me.

Thanks for your time and clarifications.