SIOS SANless clusters High-availability Machine Learning monitoring
What happens in a SQL Server disaster? Here’s your chance to be part of the action.
This webinar guides you through a few simulated disasters of SQL Server. Walk away from this webinar with a DR plan and a checklist to ensure your business operations run as expected in the event of an outage.
As discussed earlier, once a High Availability cluster has been configured, two or more nodes run simultaneously and users connect to the “active” node. When an issue occurs on the active node, a “failover” condition occurs and the “standby” node becomes the new “active” node. When a failover occurs there must be a mechanism that either allows a client to detect the failover condition and to reconnect, or a seamless transfer of the user’s active client session to the active node.
Usually a “virtual” IP address is created when a cluster is configured and the client communicates with the active node using a virtual IP address. When a failover occurs, the virtual IP address is reassigned to the new active node and the client reconnects to the same virtual IP address.
As an example, let us assume that there are two nodes, A and B, with IP addresses of 10.20.1.10 and 10.20.2.10. In this example, we will define a virtual IP address of 10.20.0.10 which should be considered to be assigned to the current active node.
This is similar to assigning a second IP address to one network interface card on one node. If the command ip a is entered on the active node, both IP addresses will appear (as on lines 10 and 12 in this Linux example):
When a client attempts to find a server using an IP address, the client typically uses ARP (Address Resolution Protocol) to find the MAC (Media Access Control) address of the target machine.
Once a client broadcasts a message to find the target IP address, the active node answers with its MAC address and the client resolves the request and connects to it.
In the cloud environment, however, it is not possible to identify the active node using ARP as many layers are abstracted in the virtual environment. An alternative method based on the network infrastructure in use in the specific cloud environment may be required. There are normally several options, and a selection should be made from the following list.
Determining how Workloads (nodes) should be distributed is a common topic of discussion when migrating to the public cloud with High Availability in mind. If workloads are located within an on-premise environment, more often than not the locations of these workloads are defined by the location(s) of established datacenters. In many cases choosing another location in which to host a workload is not an available option. With a public cloud offering there are a wide range of geographical regions as well as availability zones to choose from.
An Availability Zone is generally analogous to one or more datacenters (physical locations) being located in the same physical region (e.g., in California). These datacenters may be located in different areas but are connected using high-speed networks to minimize connection latency between them. (Note that hosting services across several datacenters within an availability region should be transparent to the user).
As a general rule, the greater the physical distance between workloads, the more resilient the environment becomes. It’s a reasonable assumption that natural disasters such as earthquakes won’t affect different regions at the same time (e.g., both U.S. west coast and east coast at the same time). However, there is still a chance of experiencing service outages across different regions simultaneously due to system-wide failures (some cloud providers have previously reported simultaneous cross-region outages such as in the US & Australia). It may be appropriate to consider creating a DR (disaster recovery) plan defined across different cloud providers.
Another perspective worthy of consideration is the cost to protect the resources. Generally the greater the distance between workloads, the more costs are incurred for data transfer. In many cases, data transfer between nodes within the same datacenter (Availability Zone) is free while it might costs $0.01/GB or more to transfer data across Availability Zones. This additional cost might be doubled (or more) when data is transferred across regions (i.e. $0.02 / GB). In addition, due to the increased physical distance between workloads, greater data latency between nodes should be anticipated between locations. Through consideration of these factors, generally speaking, it is recommended to distribute workloads across Availability Zones within the same Region.
In some way or another, the world-changing events of 2020 and 2021 have reshaped nearly everything that we knew, and high availability was no exception. Despite closures and restrictions, many IT teams traded on-prem data centers for the cloud. Many are asking, ‘Now what?’ Here are five things to do to fix your cloud journey in 2022.
In the push to the cloud many IT and business leaders found themselves rushing to move services and applications from data centers that they were closing due to COVID-19 into the cloud. Others rushed to the cloud, not because of data center closures, but to deal with the wave of exploding demand. For some, the journey to the cloud was so fast that HA wasn’t included, and now they’ve discovered the hard way that applications still crash in the cloud and that unexpected outages and unplanned downtime are still the nemesis of AWS, Azure and GCP as much as they were in their previous data center.
The first step in fixing your cloud journey is to add a c. This will mean several things to your enterprise:
Of course, not everyone made the move to cloud without considering some form of HA. Some IT teams had the foresight to not leave HA on-premises, but in the rush to cloud moved all of their critical servers to the same cloud Availability Zone. While having some HA protections is better than complete vulnerability, if you’ve only deployed your servers and applications in a single Availability Zone (AZ), now is the time to expand to multi-AZ for your standby cluster node, or even build in disaster recovery by deploying a third node in a different region. SIOS’ has helped dozens of customers plan multiple-AZ architectures and add disaster recovery solutions.
Overnight some companies, and their IT teams, went from being fully on-premises to wrestling with Cloud Formation Templates, QuickStart Guides, IAM roles, internal load balancers, Overlay IPs, and deciphering what exactly that VM size means. Now is the time to build a team to support the journey to the cloud. This will mean several things:
As VP of Customer Experience at SIOS Technology Corp. I have worked with several companies that made the move to the cloud in 2021 without sacrificing HA, DR or their team. If you took achieving the required number of nines of uptime (99.99%) seriously and having a disaster plan was non-negotiable then it’s time to add the rigor of analytics and additional monitoring. Ensure that your availability solution has application-aware automation and orchestration for recovery in the event of a disaster or unplanned downtime. Add analytics and automation to solidify your solution and take your cloud migration up another notch from one of reactive failovers to proactive notification and mitigation of the failure before it occurs. Imagine being notified of underperforming applications, or of increasing latency, errors, or VM non-responsive behavior in time to avoid downtime in the peak business times. Analytics are also important as they can reveal systems and applications that may have escaped your original availability architecture.
Many things we think of as a failure are rooted in a failure of process. Make sure that your organization’s processes are up to date, well-documented, properly communicated and adhered to. These processes should contain a few key minimums related to who, what, when, where, and how all tied back to the business strategies, goals, and organizational needs as they pertain to the customer.
Make sure that ownership and sign-off processes for your new cloud environment are well-documented. I have seen firsthand the frustration that comes from conflicting, clashing or unresolved roles and responsibilities for customers who have moved from hardware teams that acquire infrastructure to cloud teams. Muddling through a migration is one set of pain points, digging out of a disaster without clear governance is a much bigger, more costly issue.
If you’ve made the leap to cloud, staying there and making it work for you is the next part of the journey. If your cloud journey was sudden or rocky, consider these five points for fixing your cloud journey and know that SIOS Technology can help you improve not only your high availability in the cloud, but also your processes for running in the cloud.
Reproduced with permission from SIOS
If this topic sounds confusing, we get it. With our experts’ advice, we hope to temper your apprehensions – while also raising some important considerations for your organisation before or after going multi-cloud. Planning for disaster recovery is a common point of confusion for companies employing cloud computing, especially when it involves multiple cloud providers.
It’s taxing enough to ensure data protection and disaster recovery (DR) when all data is located on-premises. But today many companies have data on-premises as well as with multiple cloud providers, a hybrid strategy that may make good business sense but can create challenges for those tasked with data protection. Before we delve into the details, let’s define the key terms.
Multi-cloud is the utilization of two or more cloud providers to serve an organization’s IT services and infrastructure. A multi-cloud approach typically consists of a combination of major public cloud providers, namely Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.
Organizations choose the best services from each cloud provider based on costs, technical requirements, geographic availability, and other factors. This may mean that a company uses Google Cloud for development/test, while using AWS for disaster recovery, and Microsoft Azure to process business analytics data.
Multi-cloud differs from hybrid cloud which refers to computing environments that mix on-premises infrastructure, private cloud services, and a public cloud.
Meeting these challenges requires companies to develop a data protection and recovery strategy that covers numerous issues. Try asking yourself the following strategic questions:
The biggest key to success in data protection and recovery in a multi-cloud scenario is ensuring you have visibility into all of your data, no matter how it’s stored. Tools from companies enable you to define which data and applications should be recovered in a disaster scenario and how to do it – whether from a backup image or by moving data to a newly created VM in the cloud, for example.
The tool should help you orchestrate the recovery scenario and, importantly, test it. If the tool is well integrated with your data backup tool, it can also allow you to use backups as a source of recovery data, even if the data is stored in different locations – like multiple clouds. Our most recent SIOS webinar discusses this same point; watch it here if you’re interested. SIOS Datakeeper lets you run your business-critical applications in a flexible, scalable cloud environment, such as Amazon Web Services (AWS), Azure, and Google Cloud Platform without sacrificing performance, high availability or disaster protection. SIOS DataKeeper is available in the AWS Marketplace and the only Azure certified high availability software for WSFC offered in the Azure Marketplace.