The Purpose of the a9s Consul DNS for PCF tile

This topic describes why you might want to install a9s Consul DNS for Pivotal Cloud Foundry (PCF).

Key Features

The a9s Consul DNS for PCF tile provides an internal DNS system to the other a9s service tiles for PCF, such as a9s MongoDB and a9s PostgreSQL. The service tiles use this internal DNS system to do the following:

  • Make service bindings independent from IP addresses: When developers bind an a9s service instance to their Cloud Foundry app, they can provide a hostname instead of an IP address. Developers then do not need to recreate the service binding if the IP address of a node in the service cluster changes.
  • Provide an infrastructure-independent failover mechanism: Consider apps that use a9s PostgreSQL for PCF. They connect to a9s PostgreSQL clusters using the hostname of a single master node that accepts write requests. The node that is currently the master node changes often. With a9s Consul DNS, the cluster can use a hostname that always resolves to the IP of the current master mode. This means the service binding requires no change when the master node changes.
  • Act as a service registry: The other a9s tiles use a9s Consul DNS as a service registry for their internal components. The anynines dataservice framework (DSF) also uses Consul watches to realize a choreography pattern within the microservice architecture.
  • Provide infrastructure-independent load balancing using Consul DNS round robin capabilities. Currently, none of a9s services for PCF use this feature.

Why a9s Services Do Not Use NGINX/HAProxy

Although proxies can solve the issue of IP propagation, they also introduce a layer of complexity. For a service such as PostgreSQL, drivers expect only one node to contact, which makes a proxy a single point of failure and removes most of the advantages of high availability. Another idea is to deploy multiple proxies within a hot-standby setup, which adds even more complexity, as an IaaS specific failover needs to be implemented.

Why a9s Services Do Not Use Static IPs

Although it sounds tempting to use the IPs of service instances in service bindings, there is a major downside to that. Depending on the IaaS, it might not be possible to resurrect VMs with static IPs if the compute node containing it is currently down. The anynines DSF aims to support all network types. This includes dynamic networks in which crashed VMs get new IP address when they are restarted. In this case it would be necessary to recreate all service bindings.