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).
If implementing your own app it’s your responsibility to call
ip.mark_policy_records_dirtyif the IP changes, so that zinc’s reconcile loop will actually pick up the changes.
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).
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.
Traffic will be routed to all IP’s based on their weights. Bigger weight means more traffic.
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
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).