Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add dashboard example

...

Services are advertised in DNS.  The Consul Servers can by queried directly via a DNS forwarder, for instance, alternatively the Consul server can update GÉANT's DNS infrastructure but periodically pushing DNS zone files to Infoblox.  A DNS query port on a consul server is a single point of failure so pushing a zone file to Infoblox is a more appropriate solution.

Example for the

...

As an example consider the Atlassian Crowd service deployed onto two servers:

prod-crowd01.geant.org

  • location: Frankfurt PoP
  • IP: 1.1.1.10
  • service name: crowd
  • consul agent

prod-crowd02.geant.org

  • location: City House PoP
  • IP: 1.1.1.11
  • service name: crowd
  • consul agent

consul-server01(02 and 03)

  • consul agent

Infoblox (DNS):

  • zone: geant.services
    • crowd
      • IP: 1.1.1.10
      • IP: 1.1.1.11

In the above setup, a client connection connects to crowd.geant.services, the DNS lookup will return either 1.1.1.10 or 1.1.1.11 (it doesn't matter as long as crowd works on them both).  If the crowd service on prod-crowd02 fails (or the server fails, or if there are connectivity problems), the consul server detects this and updates the zone file to look like this:

Infloblox:

  • zone: geant.services
    • crowd
      • IP: 1.1.1.10

In this case, a lookup of crowd.geant.services will return 1.1.1.10 only.

...

dashboard service (using the image above)

In the images above there are two linux (VMs) each running dashboard. In addition node 1 also hosts an instance of cacti and node 2 the bodportal.  Each node runs the Consul agent in "client" mode and registers all the services it knows about with the Consul server.  The consul server periodically assembles all registered services into a DNS zonefile which it pushes to the DNS infrastructure (which in GÉANT is Infoblox).  In the example here, the zonefile will contain two entries for dashboard and one each for cacti and bodportal.

When a web client loads dashboard, the DNS query returns one of the IPs it has for dashboard; above, node2 is returned.

The consul server continues to accept service registrations from consul clients as well as actively monitoring the health of registered services.  So, for instance, should the dashboard instance on node 2 fail, the consul server will identify this and remove the node 2 IP for dashboard the DNS zonefile.  The next time a client loads dashboard it will only be offered the IP for node 1.

Summary - components 

Consul: provides service discovery

...