October 22, 2021 |
Disaster Recovery Made SimpleDisaster Recovery Made SimpleDisaster Recovery Made SimpleHeard the term disaster recovery (DR) thrown around often? DR is a strategy and set of policies, procedures, and tools. It ensures critical IT systems, databases, and applications continue to operate and be available to users when a man-made or natural disaster happens. It typically involves moving application operation to a redundant DR environment that is geographically separated from the primary environment. While the IT team owns the disaster recovery strategy, DR is an important component of every organization’s Business Continuity Plan. The latter is a strategy and set of policies, procedures, and tools to ensure business operations continue through an interruption in service. It may sound confusing at first. But we’ve collected some quick facts to make disaster recovery simple to understand: Point 1. Implement an IT disaster recovery or a disaster recovery plan (DRP)A DRP is a strategy and set of policies, procedures, and tools that ensure critical IT systems, databases, and applications continue to operate and be available to users when a disaster strikes the organization’s primary computing environment. While the IT team owns the disaster recovery strategy, DR is an important component of every organization’s Business Continuity Plan. Point 2. Ensure Geographic SeparationAn essential part of application disaster recovery is ensuring there is a redundant, geographically separated application environment available. You have either efficient, block level replication and or a clustering software that can failover operation to it in the event of a disaster. If your application is running in a cloud, your clustering environment should failover across cloud regions and availability zones for disaster recovery. Point 3. Test, test, and test some moreIn a recent Spiceworks survey, 59 percent of organizations indicated they had experienced one to three outages (that is, any interruption to normal levels of IT-related service) over the course of one year. 11 percent have experienced four to six. 7 percent have experienced seven or more. In short, a DR event is nearly inevitable. Be sure you conduct regular testing to ensure you know exactly what will happen when it does. Point 4. Understand Your RiskThe disaster in DR does not need to be a full-fledged hurricane, tornado, flood, or earthquake that impacts your business. Disasters come in many forms, including a cyber-attack, fire, theft, or vandalism. In fact, simple human error still rates among the leading causes of IT data center downtime. In short, a disaster is any crisis that results in a down system for a long duration and/or major data loss on a large scale that impacts your IT infrastructure, data center, and your business. Point 5. Ensure Your DRP has a ChecklistIt should include critical IT systems and network prioritized by their expected time for recovery (RTO). Document the steps needed to restart, reconfigure and recover systems and networks. Employees should know where to locate the DRP and how to execute basic emergency steps in the event of an unforeseen incident. Point 6. Substantiate DRPs through testingDRPs should identify deficiencies and provides opportunities to fix problems before a disaster occurs. Testing can offer proof that the plan is effective and that it will enable you to meet recovery point and recovery time objectives (RPOs and RTOs). Since IT systems and technologies are constantly changing, DR testing also helps ensure a disaster recovery plan is up to date. Choose a failover clustering technology that makes DR testing simple by facilitating fast, simple, reliable switchover of application operation to DR nodes and back. When you look at those statistics, you know you are living on borrowed time if you don’t have a disaster recovery plan in place. The SIOS disaster recovery solution is a multi-site, geographically dispersed cluster that meets RPO and RTOs with ease. What makes SIOS different from many other DR providers is that it offers one solution that meets both high availability and disaster recovery needs. To learn more about our DR solutions, check out the insights page here. Reproduced with permission from SIOS |
||||||||||||||||
October 16, 2021 |
Enhanced High Availability for SAP S/4HANA in Cloud Environments |
||||||||||||||||
October 10, 2021 |
RTO vs. RPO: Learning the Difference to Achieve Your Operational GoalsRTO vs. RPO: Learning the Difference to Achieve Your Operational GoalsIn addition to 99.99% availability time, high availability environments also need to meet stringent recovery time and recovery point objectives, RTO and RPO, respectively. RTO and RPO are two key parameters that businesses should define before creating their business continuity and disaster recovery plans. Both metrics help to design the recovery process, and to define the recovery time limits, the frequency of backups, and the recovery procedures. Although RTO and RPO may seem alike, there are core differences you should consider. Read on to understand the difference between RTO vs. RPO. To be clear, RTO is a measure of the time elapsed from application failure to restoration of application operation. It is a measure that dictates how much time you have to recover after disaster strikes. On the other hand, RPO is a measure of how up-to-date the data is when application availability has been restored after a downtime issue. It is often described as the maximum amount of data loss that can be tolerated when a failure happens. Things to consider for evaluating your disaster recovery planFirst, it’s important to define the criticality of the application and its associated data to core business operations. How much does a minute of downtime or data loss for this application cost the company? Next, consider the potential set of disasters against which you would like to protect your organization. Some disasters that require data recovery and backup include:
Reducing an organization’s RPO and RTOIt’s important to consider the RTO and RPO as they apply to different types of data. Organizations that do a file-level backup of a database, rather than investing in an offsite virtual environment, will see longer recovery times and limits to how recently updated that data will be once recovered. Consider the possible disasters, match them with the data sets that need to be protected, and then identify the recovery objectives. These steps will then provide you the information necessary to build tactical backup solutions that meet your recovery time objective and recovery point objective. What is RTO and RPO in SQL Server?SQL Server allows users to set up automated log backups to be restored from a standby server. With this log shipping, users can recover a fairly recent database copy—depending on the RTO and RPO of that process. Those RTO and RPO requirements are set by users, depending on their needs, budget, and any technological network limitations. However, SQL Server RTO and RPO are not necessarily straightforward. In many cases, the process isn’t as fast as a client may imagine. They may have an ideal RPO in mind, but slow network speeds or an incorrectly configured backup can throttle this process. In addition, restoring a log backup in this way can involve transferring large amounts of data, and this process can easily exceed the determined acceptable RTO. Since SQL Server is typically a business-critical application, customers can easily justify HA/DR protection for it – usually in the form of a failover cluster that can failover across cloud availability zones and regions for disaster recovery. This can be accomplished easily by adding SIOS DataKeeper to a Windows Server Failover Clustering environment or by using SIOS Protection Suite in a Linux environment. Both of these solutions will deliver not only 99.99% availability but also RPO of zero and RTO of mere seconds. Now that you know… Ultimately, data loss prevention for business continuity is a crucial requirement for any business. Take the time to consider how you will meet your RTO and RPO goals, no matter how large or small your business is, or what internal IT operations you support. SIOS high availability clusters deliver an RPO of zero and an RTO of mere minutes. Learn more about SIOS DataKeeper for Windows or SIOS Protection Suite for Linux To request a free trial, let us know here. Reproduced from SIOS |
||||||||||||||||
October 5, 2021 |
SIOS Announces New Version 8.8 of SIOS Protection Suite for Windows |
||||||||||||||||
September 28, 2021 |
Deployment of a SQL Server Failover Cluster Instance on Huawei CloudDeployment of a SQL Server Failover Cluster Instance on Huawei Cloud*DISCLAIMER: While the following completely covers the high availability portion within the scope of our product, this is a setup “guide” only and should be adapted to your own configuration. OverviewHUAWEI CLOUD is a leading cloud service provider not just in China but also has global footprint with many datacenters around the world. They bring Huawei’s 30-plus years of expertise together in ICT infrastructure products and solutions and are committed to providing reliable, secure, and cost-effective cloud services to empower applications, harness the power of data, and help organizations of all sizes grow in today’s intelligent world. HUAWEI CLOUD is also committed to bringing affordable, effective, and reliable cloud and AI services through technological innovation. DataKeeper Cluster Edition provides replication in a virtual private cloud (VPC) within a single region across availability zones for the Huawei cloud. In this particular SQL Server clustering example, we will launch four instances (one domain controller instance, two SQL Server instances and a quorum/witness instance) into three availability zones. DataKeeper Cluster Edition provides support for a data replication node outside of the cluster with all nodes in Huawei cloud. In this particular SQL Server clustering example, four instances are launched (one domain controller instance, two SQL Server instances and a quorum/witness instance) into three availability zones. Then an additional DataKeeper instance is launched in a second region including a VPN instance in both regions. Please see Configuration of Data Replication From a Cluster Node to External DR Site for more information. For additional information on using multiple regions please see Connecting Two VPCs in Different Regions. DataKeeper Cluster Edition also provides support for a data replication node outside of the cluster with only the node outside of the cluster in Huawei Cloud. In this particular SQL Server clustering example, WSFC1 and WSFC2 are in an on-site cluster replicating to a Huawei Cloud instance. Then an additional DataKeeper instance is launched in a region in Huawei Cloud. Please see Configuration of Data Replication From a Cluster Node to External DR Site for more information. Requirements
Release NotesBefore beginning, make sure you read the DataKeeper Cluster Edition Release Notes for the latest information. It is highly recommended that you read and understand the DataKeeper Cluster Edition Installation Guide. Create a Virtual Private Cloud (VPC)A virtual private cloud is the first object you create when using DataKeeper Cluster Edition. *A virtual Private Cloud (VPC) is an isolated private cloud consisting of a configurable pool of shared computing resources in a public cloud.
*A Route Table will automatically be created with a “main” association to the new VPC. You can use it later or create another Route Table. *HELPFUL LINK: Launch an InstanceThe following walks you through launching an instance into your subnet. You will want to launch two instances into one availability zone, one for your domain controller instance and one for your SQL instance. Then you will launch another SQL instance into another availability zone and a quorum witness instance into yet another availability zone. *HELPFUL LINKS:
*IMPORTANT: Make a note of this initial administrator password. It will be needed to log on to your instance. Repeat the above steps for all instances. Connect to InstancesYou can connect to your domain controller instance via Remote Login from the ECS pane. Login as administrator and enter your administrator password. *BEST PRACTICE: Once logged on, it is best practice to change your password. Configure the Domain Controller InstanceNow that the instances have been created, we started with setting up the Domain Service instance. This guide is not a tutorial on how to set up an Active Domain server instance. We recommend reading articles on how to set up and configure an Active Directory server. It is very important to understand that even though the instance is running in a Huawei cloud, this is a regular installation of Active Directory. Static IP AddressesConfigure Static IP Addresses for your Instances
Join the Two SQL Instances and the Witness Instance to Domain*Before attempting to join a domain make these network adjustments. On your network adapter, Add/Change the Preferred DNS server to the new Domain Controller address and its DNS server. Use ipconfig /flushdns to refresh the DNS search list after this change. Do this before attempting to join the Domain. *Ensure that Core Networking and File and Printer Sharing options are permitted in Windows Firewall.
*Use Control Panel to make sure all instances are using the correct time zone for your location. *BEST PRACTICE: It is recommend that the System Page File is set to system managed (not automatic) and to always use the C: drive. Control Panel > Advanced system settings > Performance > Settings > Advanced > Virtual Memory. Select System managed size, Volume C: only, then select Set to save. Assign Secondary Private IPs to the Two SQL InstancesIn addition to the Primary IP, you will need to add three additional IPs (Secondary IPs) to the elastic network interface for each SQL instance.
*HELPFUL LINKS: Create and Attach VolumesDataKeeper is a block-level volume replication solution and requires that each node in the cluster have additional volume(s) (other than the system drive) that are the same size and same drive letters. Please review Volume Considerations for additional information regarding storage requirements. Create VolumesCreate two volumes in each availability zone for each SQL server instance, a total of four volumes.
*HELPFUL LINKS: Configure the ClusterPrior to installing DataKeeper Cluster Edition, it is important to have Windows Server configured as a cluster using either a node majority quorum (if there is an odd number of nodes) or a node and file share majority quorum (if there is an even number of nodes). Consult the Microsoft documentation on clustering in addition to this topic for step-by-step instructions. Note: Microsoft released a hotfix for Windows 2008R2 that allows disabling of a node’s vote which may help achieve a higher level of availability in certain multi-site cluster configurations. Add Failover ClusteringAdd the Failover Clustering feature to both SQL instances.
Validate a Configuration
Note: To search, select Browse, then click on Advanced and Find Now. This will list available instances.
Create Cluster
Configure Quorum/Witness
Install and Configure DataKeeperAfter the basic cluster is configured but prior to any cluster resources being created, install and license DataKeeper Cluster Edition on all cluster nodes. See the DataKeeper Cluster Edition Installation Guide for detailed instructions.
*Note: The domain or server account used must be added to the Local System Administrators Group. The account must have administrator privileges on each server that DataKeeper is installed on. Refer to DataKeeper Service Log On ID and Password Selection for additional information.
*Note: If installing DataKeeper Cluster Edition on Windows “Core” (GUI-less Windows), make sure to read Installing and Using DataKeeper on Windows 2008R2/2012 Server Core Platforms for detailed instructions. Configure MSDTC
*For Windows Server 2008, in the Failover Cluster Manager GUI, select Services and Applications, then select Configure a Service or Application and click Next.
Install SQL on the First SQL Instance
F:\>Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster
Install SQL on the Second SQL InstanceInstalling the second SQL instance is similar to the first one.
Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER” (Note: This assumes you installed the default instance on the first node)
Common Cluster ConfigurationThis section describes a common 2-node replicated cluster configuration.
!IMPORTANT: Make sure that Virtual Network Names for NIC connections are identical on all cluster nodes.
Connectivity to the cluster (virtual) IPsIn addition to the Primary IP and secondary IP, you will also need to configure the virtual IP addresses in the Huawei Cloud so that they can be routed to the active node.
ManagementOnce a DataKeeper volume is registered with Windows Server Failover Clustering, all of the management of that volume will be done through the Windows Server Failover Clustering interface. All of the management functions normally available in DataKeeper will be disabled on any volume that is under cluster control. Instead, the DataKeeper Volume cluster resource will control the mirror direction, so when a DataKeeper Volume comes online on a node, that node becomes the source of the mirror. The properties of the DataKeeper Volume cluster resource also display basic mirroring information such as the source, target, type and state of the mirror. TroubleshootingUse the following resources to help troubleshoot issues:
Additional Resources:Step-by-Step: Configuring a 2-Node Multi-Site Cluster on Windows Server 2008 R2 – Part 1 — http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-1/ Step-by-Step: Configuring a 2-Node Multi-Site Cluster on Windows Server 2008 R2 – Part 3 — http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-3/ |