4 Responses Nov 5
Naren Work:
DNS Failover
Without a doubt, DNS failover is a failover solution that enhances the automatic transfer of traffic to the secondary server during times of fault when the pre-determined website or internet connection goes offline (Hunter & Porter 2018). The DNS failover operates faster before a client can have access to the servers, thus making the failover operations more efficient and relatively inexpensive. In the event of downtime, which could be caused by unforeseen system failure or scheduled management of the system, information is swiftly en-route from the primary method to the secondary system before any client access it.
By definition, cloud failover refers to a failover solution that immediately after the DNS in the network layer (Hunter & Porter 2018). In particular, its way of operation is similar to that of DNS failover in a way that it also happens before any client connects to the application. Cloud Failover also monitors the secondary system following the programmed monitoring criteria found in the cloud interface. In case of occurrence of any fault, cloud failover redirects traffic to the secondary server in a traditional manner, which is majorly hardware-based (Hunter & Porter, 2018). This feature makes the cloud failover solution relatively expensive as compared to the DNS failover solution because the maintenance of the hardware components of the system, together with their setup, is always very demanding in terms of finance.
To overcome the limitations of the two individual failover solutions, they can be combined to operate as a single solution mechanism called DNS Cloud Failover solution. “Efficiently placing and managing primary and backup replicas of applications in distributed Clouds to achieve HAP is a challenging task” (Aldwyan & Sinnott, 2019). During downtime, the two devices work collectively to redirect instructions to the secondary server quickly. This combination, therefore, ensures robust protection of the applications during the occurrence of the unforeseen fault by quickly en-routing applications from the primary to the secondary site. This collective responsibility, therefore, enhances rapid failback immediately; the main system resumes regular operation.
The DNS Cloud Failover solution enhances the easy recognition of an outage (Hunter & Porter 2018). The combined solution mechanism has a robust monitoring system for close monitoring of the active server IP addresses during operations. In case of occurrence of an abrupt fault, the monitoring system will notify the operator, who consequently responds by initiating the failover process immediately. “The monitoring system will alert you that it is back online, but you have to manually force it to start receiving traffic again” (Sousa & Cordeiro, 2017). The monitoring feature of the system gives an alert immediately the outage occurs or when the system comes back online to meet the recovery time objective to avoid unnecessary consequences by enhancing service restoration in time (Song & Tilevich, 2019).
In a nutshell, the combined failover solution is relatively inexpensive (Sousa & Cordeiro, 2017). The DNS Cloud failover solution is a modernized approach for resolving a failover and is therefore not entirely based on the hardware system, which is usually expensive to operate and maintain. “The appliance-based solutions are inevitably more costly and demanding from a setup and maintenance point of view” (Hunter & Porter, 2018). This feature of the combined failover mechanism for a solution makes the system relatively inexpensive and easy to control.
References
Aldwyan, Y., & Sinnott, R. O. (2019). Latency-aware failover strategies for containerized web applications in distributed clouds. Future Generation Computer Systems, 101, 1081-1095.
Hunter, T., & Porter, S. (2018). Google Cloud Platform for Developers: Build highly scalable cloud solutions with the power of Google Cloud Platform. Packt Publishing Ltd.
Song, Z., & Tilevich, E. (2019, July). Equivalence-enhanced microservice workflow orchestration to efficiently increase reliability. In 2019 IEEE International Conference on Web Services (ICWS) (pp. 426-433). IEEE.
Sousa, B., Fonseca, V., Simoes, P., & Cordeiro, L. (2017, May). Evaluation of scalable, on-demand DNS-as-a-Service. In 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM) (pp. 766-771). IEEE.
Dushyanth Work:
DNS and Cloud Failover
Failover refers to the switching of applications to their redundant or standby counterparts. The applications include computer services, systems and hardware. The failover process is usually automatic and requires no human intervention. On the other hand, switchover is manual and has to rely on human intervention. The discussion wishes to assess the comparison between DNS and Cloud Failover.
The difference between the failovers lie in the applications that have the capability to transfer operations from the defective to the operational system. The DNS failover runs under the automation of the DNS Made Easy monitoring systems (Blue Itech, 2016). The systems detect the protocols that the services are operating on. The failure of the services to be detected in two or more different geographic monitoring locations leads to automatic transmission (Blue Itech, 2016). The protocols used include the TCP, UDP, HTTP, or HTTPS.
The article shows that, “If used in conjunction with our System Monitoring service, an email will be sent immediately notifying your contact email address of the outage” (Blue Itech, 2016). The users have to link their PC to the systems to ensure they get the updates. They should also install the Peregrine Instant DNS Propagation to foster the detection of the available back-up IP (Blue Itech, 2016). The article shows that users can revert to their primary IP given its has regained functionality.
The success of the DNS failover relies on the reliability of the DNS configuration. “Within the DNS Made Easy interface you would define the back up IP address, protocol and port to monitor as well as a notify contact list for system monitoring if you wish” (Blue Itech, 2016). Therefore, the users have to configure the processes that the system can autonomously execute. They state the backup IP address for transfer, which can be as many as five (Blue Itech, 2016). The large number of IP addresses increases the probability of getting an available IP address given there is an attack.
On the other hand, the cloud failover requires a cloud-based platform. Risetto (2016) gave the example of the AWS and Azure platforms. It involved utilization of the two platforms as backups. “On the positive side the article presented a neat and robust HA/DR solution for AWS cloud implementations, the downside though is the cost of the SQL Server 2014 Enterprise Edition used in the solution” (Risetto (2016). The management has to ensure the benefits of the two applications exceeds the costs.
Berm (2014) addressed the issue of cost in Cloud failover by showing that Azure can be used alone. The article emphasized that the user needs to ensure the approach improve data availability and disaster recovery. “This post contains step-by-step instructions for implementing a Windows Server Failover Cluster in the Windows Azure IaaS Cloud between two cluster nodes in different Fault Domains” (Berm, 2014). The instructions allow the users provide two Windows Server 2012 R2 Servers. They also cite the need for formulating clusters and backed up volume cluster resource.
References
Berm, D. (2014, January 10). Creating A SQL Server 2014 Always on Failover Cluster (FCI) Instance In Windows Azure Iaas #Azure #Cloud. Clustering for Mere Mortals
Blue Itech.(2014, March 7). DNS Failover System. Retrieved from https://www.blueitech.com/news/dns-failover-system/
Risetto, R. (2016, September 11). SQL Server Failover between AWS and Azure using SQL 2014 Standard Edition. DB Insights