IPs, Policies and Policy Records

IPs

Should be self explanatory. An IP can be enabled or disabled.

There is no explicit handling in zinc of multiple IPs belonging to one server.

Enabling or disabling can be done from the admin or by implementing a Django app (see lattice_sync for an example).

NOTE

If implementing your own app it’s your responsibility to call ip.mark_policy_records_dirty if the IP changes, so that zinc’s reconcile loop will actually pick up the changes.

HealthChecks

Zinc will create a Route53 Health Check for each IP. If Route53 deems the IP unavailable, it will stop routing traffic to it.

Currently the Health Checks are hardcoded to expect all servers to accept requests with the same FQDN (defaults to node.presslabs.net, set ZINC_HEALTH_CHECK_FQDN to change).

Policies

A policy groups several IPs together. There are 2 types of policies:

• Weighted
• Latency

Note that an IP can be a member of multiple Policies at the same time. A PolicyMember can has it’s own enabled flag, so you can disable an IP for one Policy only, or you can disable the it for all Policies by setting the enabled flag on the IP model.

Weighted

Traffic will be routed to all IP’s based on their weights. Bigger weight means more traffic.

Latency

Each IP you add to a Policy will have a region specified as well. The region must be an AWS region. IPs will still have weights, which will be used to balance the traffic within a region. When a client does a DNS lookup, they’ll get directed to the region with the lowest latency, and then an IP will be picked based on weight.

The resulting setup will be similar to the example described here: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-complex-configs.html

Policy Records

Your desired DNS record. In Route53 it will be an alias to the Latency or Weighted records that make up a Policy.

Reconcile Loops and the Single Source of Truth

For simple records in a zone (anything except a PolicyRecord) AWS is the Single Source of Truth. Zinc never stores those locally.

For Zones, HealthChecks and PolicyRecords Zinc’s database is the single source of truth. Zinc runs reconcile loops and attempts to update your AWS data to match the expected state in the DB. To minimise throttling by AWS, in most cases, Zinc only attempts to reconcile objects marked deemed dirty. This means it is possible to have a mismatch between what you have in AWS and Zinc’s expected state if you make changes bypassing Zinc (using the AWS console, or the api).