Failover automatically moves your traffic from unavailable resources to healthy ones. DNS Failover is natively integrated with almost all of our services:
Failover is supported for A, AAAA, ANAME, and CNAME records.
The "most affordable" and "easiest to configure" kind of load balancing.
All you need to do is enable Failover for your record, and specify the IP addresses or hostnames of your "backup" resources. These backups are only used when the primary IP/hostname is unavailable.
There are three setting for enhanced failover. Rankings determine the order the backup IP addresses will be served when the primary IP in unavailable.
|Ranking Mode||Description||How It Works|
|Normal||Always lowest levels||Attempt to keep the IP address to the most preferred system in the list.|
|Off On Any Failover||Move to an active IP||Turn off failover after any failover.|
|One Way||Move to higher levels||Only failover your domains to IPs that are further down the list. For example, IP #1 will failover to #2, and #2 will failover to #3, but it will never go back to #1 unless manually changed.|
The most basic of load balancing services is called round robin. Round robin is often compared to a rotor because it returns one endpoint at a time in a cyclical manner.
Let’s say you want to point your domain to three geographically distributed web servers: 126.96.36.199 , 188.8.131.52 , and 184.108.40.206 with round robin enabled. Each time your domain is queried, it will return the next IP in the list.
The second kind of load balancing is called weighted round robin and allows you to distribute uneven amounts of traffic across your endpoints. This is great way to prioritize servers and resources in your network that have more capacity. You can also use weights to slowly roll out an update to only segments of your users at a time.
In Constellix, you need to configure weighted round robin using record pools. Pools are groups of endpoints, which are applied to DNS records. When the record is queried, it will rotate through the different endpoints in the pool at each request. We like to think of round robin pools as rotors.p>
There are many ways to customize record pools. For instance, you can choose how many endpoints are returned each time the record is queried.
But round robin isn’t a perfect system. If one of the IP’s is not responding, the record will continue to serve that IP as it is requested. If any resolving nameservers or users have that endpoint cached, it will continue to request that IP until the cache expires. This defeats the idea of using round robin as a way to add more redundancy.
You could decrease the TTL (Time to Live) for your round robin record, but this will increase your costs overtime since your nameservers will be queried more.
You can integrate monitoring checks with your round robin records. That way, only healthy endpoints are served to users. If an endpoint is detected as down, it will be removed from the rotation. But if it comes back as healthy, it will be included in the next cycle.
You can also use Round Robin with Failover if you want just one endpoint to be returned unless it is down. If it does come back as down, then we will failover the other endpoints which will be returned in a round robin fashion.
In this case, you would create two pools, one with just your primary endpoint. The second pool would contain the endpoints you want to failover to.
ITO, Internet Traffic Optimization, uses integrated monitoring checks, just like Round Robin with Failover, but it can also account for the round trip time (RTT) of the systems in your load balancing configuration.
Enable ITO in your load balancing pools and traffic will only be sent to the fastest responding resource(s). You can choose to return one or multiple resources in an ITO pool.
Latency load balancing is ideal for multi-vendor configurations like multi-CDN, multi-DDoS, or multi-cloud.
Keep in mind... Latency load balancing is configured by region, so you want to have multiple resources in whichever region you are using this feature.