Integration

Using a dedicated load balancer

The cluster thinks about itself in terms of having an API IP and/or an API Hostname. If you are using an API Hostname, it trumps the API IP when it comes time to form the X-Storage-Url value.

After you successfully authenticate, the X-Storage-Url header in the response will "point to" where the cluster is configured to think it is (API Hostname or API IP). If the client cannot talk to the cluster via that hostname or IP, then subsequent communication will fail.

Normally, what you'd do is something like this:

  1. Configure DNS: big-cluster.acme.com => 12.34.56.78
  2. 12.34.56.78 is the "outside" or "client-facing" IP of the load balancer
  3. The load balancer is configured with a pool of IPs of 192.168.10.{11..15}
  4. Configure the Cluster's API Hostname to be "big-cluster.acme.com"
  5. Depending on how your routing and the load balancer behaves, on any "internal" network, either let big-cluster.acme.com resolve to 12.34.56.78, or use DNS or /etc/hosts to make "big-cluster.acme.com" resolve to a single proxy's IP. If you end up not being able to have "internal" clients successfully do HTTP(S?) to 12.34.56.78 and have to just use a single proxy, you won't be getting load-balancing, but the connection will work.

So a client would auth against:

...and get back an X-Storage-Url like:

Another way to look at it is that any client needs to be able to reach either http://CLUSTER_API_IP/ (if Cluster API Hostname is not set)

… or:

http://CLUSTER_API_HOSTNAME/ regardless of what URL the client used to reach the authentication endpoint.

How can I monitor my nodes using Nagios?

See Nagios Integration.