The “failover after” setting (shown below) in the main Failover Pool configuration is the number of our cloud nodes (datacenters) that must see your server as DOWN before actually failing over. All of our datacenters monitor your servers all the time. This setting simply allows you to increase the reliability of the results before action […]
We’re often asked how quickly an ‘A’ or ‘AAAA’ record controlled by a DNS Failover pool can update across the internet. TLDR: 2.5 minutes is about as fast as it can go. If you’re curious how we came up with this number, here’s the backstory on how it all works. DNS Failover update speed is […]
Total Uptime’s DNS Failover automation is a powerful way of increasing availability for any type of web-based service or application that is accessible via multiple IP addresses. Some examples include: An application behind two or more different ISP links Two or more servers at the same or different sites Two or more cloud or hosting […]
Method: POST URI: /CloudDNS/Failover/Pool This method creates a new failover pool. It requires that the following information be posted in order to successfully create the domain: Field Sample data Name e.g. “My first failover pool” IPType “ipv4” or “ipv6” […]
Don’t want to read the manual? Watch the video instead! Failover Pools are lists of one or more IP addresses (IPv4 or IPv6) that can be assigned to A or AAAA records to automate record changes based on certain monitoring criteria you specify. For example, you may have a failover pool that contains the IP […]
On occasion we receive a request seeking assistance creating monitors to determine the availability of Microsoft Exchange, such as Internet-facing ActiveSync or OWA. After helping many customers, we have determined what works well, and what doesn’t work at all. Here are our tried and true suggestions for reliably monitoring your Exchange environment. Exchange 2013, 2016 […]
Yes. Our DNS Failover does have a feature to prevent “Auto Rejoin”. Unchecking this box (shown below) for any of your servers will prevent it from automatically being used again when it comes back online. This is often necessary if, after a fail over, you need to synchronize back-end data (such as a database) to the primary […]
Dealing with a DNS cache is probably the largest challenge of a DNS failover service. Even when setting the TTL for your ‘A’ record to a very low number, certain ISPs or networks just like to ignore those TTLs and elect to set the cache for a value that they deem appropriate. AOL is a prime […]
The similarities Both solutions require that you tell us what the IP address(es) are for your ‘real servers’. That way we know how to alter DNS or route traffic when one or more servers go up or down. These IP addresses must be publicly accessible, not private. Also, both solutions use the same type of […]
When implementing a failover solution, the most common questions we receive are: How can we architect a failover solution for our application? How quickly can we failover from the primary site to the secondary site? How quickly can it fail back when the primary comes back online? Is there a way to prevent automatic failback […]