Managing Traffic with Steering Policies
On Compute Cloud@Customer, offers two types of traffic steering policies based on load balancing and some value of the IP address prefix.
DNS can do more than return an IP address (if known) when given a string in the DNS namespace for that zone. DNS is also a part of a system of traffic management, where traffic is distributed among multiple servers depending on some criterion, such as location. Steering policies are a way to distribute access to a single fully-qualified name across multiple servers.
For example, the same content could be available from multiple source servers, whether it is a streaming video or records from a product database. One server might be in the United States, and the other in Europe. A traffic steering policy could distribute traffic based on IP address or CIDR. Other criteria can be used for this traffic distribution, such as load balancing, which strives to keep the load on multiple servers roughly equal.
Compute Cloud@Customer supports these types of traffic management steering policies:
|
Policy Type |
Description |
|---|---|
|
Load Balancer |
Load Balancer policies allow distribution of traffic across multiple endpoints. Endpoints can be assigned equal weights to distribute traffic evenly across the endpoints, or custom weights may be assigned for ratio load balancing. |
|
IP Prefix Steering |
IP Prefix steering policies enable you to steer DNS traffic based on the IP Prefix of the originating query. You can divide users into groups based on the subnets from where requests originate, and steer them to specific resources based on the subdivision you made. For example, you can serve different responses for your internal users as opposed to external users. |
A steering policy contains rules to answer DNS queries. You use those rules to filter answers based on the properties of the DNS request. When multiple answers are served in response to DNS queries, that group of answers is called an answer pool. The answers within a pool are sorted by priority and are marked eligible or ineligible. Ineligible answers are omitted from the response.
When attached to a DNS zone, a steering policy takes precedence over all resource records of the zone it covers, and causes DNS responses to be constructed from the steering policy rules instead. For example, if a steering policy attached to the example.com DNS zone contains a rule covering the domain application.example.com and an answer for the A (address) record type, then the steering policy responds with that answer regardless of any relevant A records that exist in the zone. If a steering policy has no answer for the record type being requested, the DNS request is passed on to the next steering policy or the base zone records.
Steering policies only support records of the types A, AAAA, CNAME. A domain can have at most one steering policy attachment covering a given record type. This means a DNS zone (example.com) may have multiple attached steering policies covering different record types for a given domain – for example, one A record policy and one CNAME record policy for application.example.com. A DNS zone may also have multiple attached steering policies covering a given record type for different domains – for example, an A record policy for application.example.com and an A record policy for database.example.com. However, multiple steering policies for the same domain and record type are not supported, because the answer can be provided by only one policy.