In theory, the server node should not synchronize the data on the client node, but this did not happen, my cluster looks like a single node
Do I need to configure anything?The following is my startup command, my consul version is v1.15.2
client node: nohup ./consul agent -data-dir=/data/consul/data -node=client -bind=10.1.252.248 -enable-script-checks=true -client 0.0.0.0 -ui > consul-server.log 2>&1 &
server node: nohup ./consul agent -server -data-dir=/data/consul/data -node=node1 -bind=10.1.12.135 -client=0.0.0.0 -bootstrap-expect=3 -ui -enable-script-checks=true -server-port=8300 -serf-lan-port=8301 -serf-wan-port=8302 -http-port=8500 -dns-port=8600 > consul-server.log 2>&1 &
After each node runs, I execute the operation of ./consul join to join the cluster
Hi @Wangyxiang, I don’t understand your question. Consul appears to be working as intended. The 360 services are registered against the client agent. The server nodes each have one service registered to them, which I assume is the consul service that is used to make the servers discoverable in the service catalog.
Is there some other behavior you were expecting to see?
That is to say, the 360 services on the client node will not be synchronized to the server node, right?I don’t quite understand the respective functions of the client node and the server node in consul. Normally, the client node will synchronize the service registration information on itself to the server node, but it doesn’t seem to happen on my side. Is there something wrong with my configuration?
This post should provide a better explanation of how service registration works against agents and how that data is aggregated in the service catalog by the servers.
If you query $CONSUL_HTTP_ADDR/v1/catalog/services, are you seeing all of your service names returned in the output? If so, the services are being successfully aggregated in the server’s service catalog.
Thanks for your reply.
I tried to use /v1/agent/service/$service_id in my client node and /v1/catalog/service/$service_name?$condition in my server node, and indeed find the corresponding registration node information.
This solves some of my previous concerns. When the client node is down, can the service data be found through other nodes?
Then,I want to ask you whether our current usage of consul is reasonable. Our node information is registered on the client node of conusl through the cmdb program, and then these services will be dynamically added to my monitoring through the automatic discovery of prometheus.
Because all our nodes are directly registered to the client node of my cluster (10.1.252.248 node in the picture), according to the scenario I described, Is our current usage of consul reasonable? Can you give me some suggestions?
The recommended deployment model is to have a Consul client agent installed on each server in your environment that is hosting your applications. The application instances on that machine should be registered with the Consul client agent that is co-located on that machine.
