SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

January 1, 2022

Four Avoidance Strategies for Improving Cluster Resilience, Performance, and Outcomes

Four Avoidance Strategies for Improving Cluster Resilience, Performance, and Outcomes

Four Avoidance Strategies for Improving Cluster Resilience, Performance, and Outcomes

Simple Steps for Deployment in SIOS Protection Suite Cluster Environment

Avoiding something – we’ve all done it before.  An old flame we see in the store while walking with our spouse, a salesperson when we aren’t “ready to buy”, and even a boss while we are out on “vacation”.  When I was the manager of a development team, I caught a glimpse of a direct report browsing in a store while they were supposed to be out of the office sick.  They ducked between clothing racks and scurried down the next aisle and hurried away.  We’ve all done it before, and in some cases, for mental health, physical health, or reasons that remain private and personal, we all need some measures of avoidance.  Even in HA.  So, how do you add avoidance to your High Availability environment, and why?

Four Reasons To Use An Avoidance Strategy In High Availability

1. Better Performance (minimizing server overload)

One reason to use avoidance strategies in HA is to increase application and server performance.  Consider the case of three servers running production workloads, let’s call them Server Alpha, Server Beta, Server Gamma.  Servers Alpha and Beta are running critical applications backed by a database, while Server Gamma is running reports and data transformation jobs.  In the event of a failure of Server Alpha, a failover to Server Beta would traditionally occur.  However, because server Beta is already running a large workload, the resulting additional application load might result in an undesirable server overload and poor performance for both applications.  So it might be wise to deploy an avoidance strategy to make sure that Server Gamma is chosen as the failover target.

2. Performance Optimization

Consider again the scenario of three servers,  Alpha, Beta, and Gamma.  Servers Alpha and Beta are scaled to handle peak workloads, while Server Gamma is a cost-optimized server.  In the event of a failure of Server Alpha and Server Beta, a failover will occur to the cost-optimized server, Gamma.  However, this server is not scaled to handle peak workloads, nor the workloads of both Server Alpha and Server Beta at the same time.  In this instance, an avoidance strategy can be used to optimize performance by automatically moving one or both of the workloads from Server Gamma as soon as another host is available.

3. High Availability Optimization

HA Optimization is another scenario for deploying avoidance strategies. Like the performance optimization strategy, HA optimization is used to ensure that your environment can survive most failure scenarios and that your applications are optimized to provide the highest level of availability possible at any point in time.  HA optimization is important for an application such as SAP with replicated enqueue processes.  In any SAP environment, you do not want the ASCS (ABAP SAP Central Service) and ERS (enqueue replication services)  instance residing on the same server for extended periods of time because of the risk of lost locks and canceled jobs. To prevent this from occurring you can use an avoidance strategy that causes the ERS and ASCS instances to always run on opposite cluster nodes.  Consider the case of three servers running production workloads, let’s call them Servers Alpha, Beta, Gamma.  Server Alpha is running the ASCS instance, while Server Beta is running the ERS instance.  Server Gamma functions as a third node for failovers of both Server Beta (ERS) and Server Alpha (ASCS).  If Beta crashes, you wouldn’t want the ERS resource running on the same node as the ASCS instance.  To ensure this operation, you can deploy an avoidance strategy that automatically checks first and ensures the two applications are on separate servers, and maintain SAP ASCS/ERS best practices for lock failover.

4. DR Avoidance

Suppose you have two data centers: City Alpha and City Beta which are about 70 miles apart with most of your clients centrally located between them. However, due to recent changes in internal organizations, mergers/closures and acquisitions, and governance requirements, your IT team has to add a third data center that is located in City Gamma, which is about 350 miles from Alpha and Beta.  Now the resources which were primarily protected in Alpha and Beta are also extended to the Gamma location.  Given that most of the users and teams are near the Alpha and Beta locations and even the most extreme users are located in neighboring cities, your team needs to avoid a failover to the Gamma location. Like the other strategies, a DR avoidance seeks to optimize performance, in/out regional data costs, latency, and client access by avoiding the DR node should only one node within either region fail.  It would also ensure that even if both nodes fail after different times, failover always occurs to the other node in the cluster or data center before moving to DR.

So, how do you deploy an avoidance strategy?  Many providers have affinity rules that can be configured, while others use a combination of server priorities or manual steps.  In the case of the SIOS Protection Suite for Linux, you can use a number of built-in methods including:

1. Resource prioritization

In the event of a failure, resources will fail over to the server where they have the lowest remaining priority and cascade to any additional servers (Alpha, Beta, and Gamma).  Server Alpha is the primary server for Resource.HR, Server Beta is the primary server for Resource.MFG, and Server Gamma is the backup server for all resources/servers.  Using resource prioritization, Resource.HR would have a priority of one (1) on Server Alpha and a priority of two (2) on Server Gamma.  While Resource.MFG could have a priority one (1) on Server Beta and a priority of two (2) on Server Gamma.  If customers wanted to optimize the use of the environment, then Resource.HR could have a priority of three (3) on Server Beta and Resource.MFG could have a priority of three (3) on Server Alpha.  In the event of a failure of Server Alpha, the resource Resource.HR would fail to Server Gamma first before trying to come in-service (be restored) on Server Alpha.

SIOS Protection Suite for Linux (UI and CLI) allow users to specify a priority for each server and resource combination.

2. Policy or affinity rules

Policy rules can also be used to prevent a resource recovery from occurring on a given server and thereby allowing a resource to avoid a specified server that may be running a more critical or resource-intensive workload.  Typical policies include:

            • Constraint policies that will block an application from a specific server by default.
            • Resource policies that will block an application from a server that does not have sufficient resources
            • Temporal policies that define a time period that resources are allowed or disallowed from a system
            • Custom policies that define preferred servers or possible application ownership abilities within the cluster.

The SIOS Protection for Linux CLI allows users to specify policy rules which can disable failover to a specific resource for a specified server, provide temporal policies guarding failures, disable failures of a specific application type, constraint policies, and custom policies.

  • Specific Avoidance Resources

The most granular way to establish a resource avoidance strategy is to deploy specific avoidance scripts within each hierarchy.  This method will allow the user to configure specific applications, (eg app1 and app2), to avoid one another whenever possible while allowing other applications to run without restriction.  In the case of our three servers, Alpha, Beta, and Gamma, and three resources app1, app2, and app3 this method would provide the greatest flexibility.  In this example, app1 and app2 will seek to avoid collocation when a server fails, but app3 will fail to the next available node based on priorities without any collocation restrictions.

For additional examples of avoidance strategies and resources, consider the SIOS Protection Suite for Linux documentation.  If a customer has two applications, app1 and app2, that they require to run on different nodes whenever possible, the customer can create two avoidance terminal leaf node resources using the SIOS Protection Suite for Linux gen/app resource and the ‘/opt/LifeKeeper/lkadm/bin/avoid_restore’ script.

– Cassius Rhue, VP, Customer Experience

Reproduced from SIOS
December 28, 2021

Windows Clustering

windows clustering - How to Achieve High Availability in Windows

Windows Clustering

Windows Clustering

How to Achieve High Availability in Windows

To mitigate system downtime and ensure high availability for Windows, IT best practice recommends that you cluster servers (or nodes) so that if one node fails, one or more other nodes automatically take over-processing. This is also referred to as Windows clustering.

Clustering software is required that monitors the health of the primary node and initiates recovery actions if it detects an issue. HA clustering also requires a way to ensure that, in the event of a failure, the secondary node is accessing the most current versions of data in storage.  In most cases, this is achieved by connecting all nodes of the cluster to the same shared storage. The cluster nodes should be separated geographically to protect applications from sitewide and regional disasters.

In Windows Server environments, Microsoft includes Windows Server Failover Clustering (WSFC) in the Windows Server platform.

What is Windows Server Failover Clustering?

With WSFC, each active node has a standby node that has the same hardware specifications and shares the same storage. A third node is often configured as a “witness” server whose sole purpose is to ensure that the primary node is operational and, if an issue is detected, to signal the need to failover operation to the standby node.

In addition to monitoring the health of the cluster, the nodes in a WSFC also work together to collectively provide:[1]

  • Resource management – Individual nodes provide physical resources such as SAN and network interfaces. The hosted applications are registered as a cluster resource and can configure startup and health dependencies upon other resources.
  • Failover coordination – Each resource is hosted on a primary node and can be automatically or manually transferred to one or more secondary nodes. Nodes and hosted applications are notified when failover occurs so that they can appropriately react. WSFC works with Microsoft Always On Availability Groups and Always On Failover Clustering to coordinate failover In Microsoft SQL Server environments.

How SIOS DataKeeper Complements WSFC

WSFC requires shared storage to ensure all cluster nodes are accessing the most up-to-date data in the event of a failover. Often, companies use expensive SAN hardware to assure data redundancy. SANs represent a single point of failure risk. And, if you want to run your application in the cloud with the same Windows Server Failover clustering protection, there is no SAN available.

SIOS DataKeeper Cluster Edition seamlessly integrates with and extends WSFC and SQL Server Always On Failover clustering by eliminating the need for shared storage. It provides performance-optimized, host-based replication to synchronize local storage in all cluster nodes, creating a SANless cluster. While WSFC manages the cluster, SIOS DataKeeper performs synchronous or asynchronous replication of the storage giving the standby nodes immediate access to the most current data in the event of a failover. SIOS DataKeeper not only eliminates the cost, complexity, and single-point-of-failure risk of a SAN, but also allows you to use the latest in fast PCIe Flash and SSD in your local storage for performance and protection in a single cost-efficient solution.

With SIOS DataKeeper, you can also balance network bandwidth and CPU utilization for each application.

  • If fast replication is critical, SIOS DataKeeper can achieve more than 90 percent bandwidth utilization to accelerate data synchronization.
  • If minimizing network impact is your top priority, SIOS DataKeeper offers integrated compression and bandwidth throttling.

In addition, SIOS DataKeeper’s Target Snapshots feature lets you run point-in-time reports from a secondary node to offload workloads that can impact performance on the primary node. This lets you query and run reports faster and make faster decisions.

Working with WSFC, SIOS DataKeeper Cluster Edition protects business-critical Windows environments, including Microsoft SQL Server, SAP, SharePoint, Lync, Dynamics, and Hyper-V using your choice of industry-standard hardware and local attached storage in a “shared-nothing” or SANless configuration.[2] SIOS DataKeeper also provides high availability and disaster recovery protection for your business-critical applications in cloud environments, such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Services without sacrificing performance.

SIOS Protection Suite – Protecting a Windows Environment Without WSFC

SIOS Protection Suite for Windows includes DataKeeper, SIOS LifeKeeper, and optional application Recovery Kits for leading application and infrastructure operations. It is a tightly integrated clustering solution that combines high availability failover clustering, continuous application monitoring, data replication, and configurable recovery policies to protect your business-critical applications and data from downtime and disasters.

Distributed metadata and notifications

The WSFC service and node’s metadata/status are hosted on each node in the cluster. When changes occur on any node, updated information is automatically propagated to all other nodes.

SIOS Protection Suite does not require WSFC as SIOS monitors the health of the application environment, including servers, operating systems, and databases. It can stop and restart an application both locally and on another cluster server at the same site or in another location. When a problem is detected, SIOS Protection Suite automatically performs the recovery actions and automatically manages cascading and prioritized failovers.

With SIOS Protection Suite, you can use your choice of SAN or SANless clusters using a wide array of storage devices, including direct-attached storage, iSCSI, Fibre Channel, and more.

SIOS Protection Suite for Windows can meet your high availability and disaster recovery needs within a single site and across multiple sites.

Popular SIOS Windows Clustering Solutions

Some of the most popular SIOS Windows clustering solutions – for SQL Server, SAP, and cloud-based environments – are discussed in more detail below.

Windows Clustering for SQL Server, SAP, S/4HANA, and Oracle

SIOS provides comprehensive SAP-certified protection for both applications and data, including high availability, data replication, and disaster recovery. To protect SAP in a Windows environment, SIOS Protection Suite includes SIOS LifeKeeper, which monitors the entire application stack. SIOS protects your Oracle Database whether you are using it with SAP or running standalone Oracle applications – you simply select the Application Recovery Kit that matches your configuration.

Windows Clustering in the Cloud

Whether you need SIOS DataKeeper to enable Windows Server Failover Clustering in the cloud or SIOS Protection Suite for Windows for application monitoring and failover orchestration, as well as efficient, block-level data replication, SIOS delivers complete configuration flexibility. SIOS allows you to create a cluster in any combination of physical, virtual, cloud, or hybrid cloud infrastructures. For example, working with WSFC, SIOS DataKeeper can:

  • Protect critical on-premise or hybrid business applications to a high availability Windows environment in AWS, Azure, or Google Cloud.
  • Protect cloud applications, such as SQL Server and SAP, by creating a Windows cluster in AWS, Azure, or Google Cloud.
  • Provide site-wide, local, or regional high availability and disaster recovery protection by failing over application instances across cloud availability zones or regions.

SIOS DataKeeper Cluster Edition can provide high availability cluster protection across cloud

Conclusion

SIOS provides offerings that support a breadth of applications, operating systems, and infrastructure environments, providing a single solution that can handle all your high availability needs. Here are just a few examples that demonstrate the power of SIOS.

  • Perth Stadium in Western Australia implemented SIOS DataKeeper with WSFC to provide high availability for their Hyper-V virtual machines.
  • PayGo (paygoutilities.com), based in the U.S., implemented SIOS DataKeeper with WSFC to provide high availability for SQL Server on AWS.
  • Toyo Gosei, based in Japan, implemented SIOS DataKeeper with WSFC to provide high availability and disaster recovery for their SAP application on Azure.

For more information on high availability/disaster recovery solutions to support your Windows environment click here [TM(1] .

References

https://www.techopedia.com/definition/24358/windows-clustering

https://searchwindowsserver.techtarget.com/definition/Windows-Server-failover-clustering

https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15

[1] https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15

[2] A shared-nothing architecture (SN) is a distributed-computing architecture in which each update request is satisfied by a single node (processor/memory/storage unit). https://en.wikipedia.org/wiki/Shared-nothing_architecture

Reproduced from SIOS
December 23, 2021

Linux Clustering

Linux Clustering

Linux Clustering

What is Linux Clustering?

A high availability Linux cluster is a group of Linux computers or nodes, storage devices that work together and are managed as a single system. In a traditional clustering configuration, two nodes are connected to shared storage (typically a SAN). With Linux clustering, an application is run on one node, and clustering software is used to monitor its operation. If the software detects an issue, it moves operation of the application to the secondary node in a process called failover. Since the secondary node shares storage with the primary, operation can continue quickly, meeting very short (seconds to minutes) recovery time and recovery point objectives.

Linux Open Source High Availability Clustering

Some Linux operating system vendors offer clustering software, such as SUSE Linux HAE; Red Hat Enterprise Linux (RHEL); and Oracle Real Application Clusters (RAC).

While they allow you to create a failover cluster, they present a variety of challenges. First, choosing which software to use for each component of the HA configuration, which at a minimum, must include three related capabilities: data replication, server clustering and a resource manager with a heartbeat monitor. With SUSE and Red Hat, you are also locked into the OS. If you want to use other less expensive or free OS versions, such as CentOS or Oracle Enterprise Linux (OEL), you will need to buy a separate HA solution.

Whichever you choose, creating a Linux clustering solution with open source software for high availability is a “Do-It-Yourself” (DIY) project, that is highly manual and prone to human error.

Linux open-source HA extensions require a high degree of technical skill, creating complexity and reliability issues that challenge most operators.

SUSE Linux Enterprise Server and Red Hat Enterprise Linux both solutions offer both a SAN and SANless environment but require that a replication software called DRBD be installed and configured in the OS to support data replication in the SANless environment. Unfortunately, this requires heavy custom scripting, which can take a long time to test and validate and requires retesting when any updates are made to the environment. Since these companies are operating system companies first and foremost, their support is geared towards operating system-level issues and often there is little to no HA expertise to help a customer with their issues.

Oracle RAC is a high availability solution, but it is primarily architected for the database management tier. This means you will need a different HA solution for those components that do the monitoring, management, and recovery of your application tiers. Oracle RAC is also very expensive – requiring you to upgrade to Oracle Enterprise Edition in addition to paying for the RAC option – typically hundreds of thousands of dollars – when compared to other Linux clustering solutions, such as SIOS Protection Suite.

SIOS Protection Suite for Linux Clustering

The SIOS Protection Suite for Linux provides a tightly integrated combination of high availability failover clustering, continuous application monitoring, data replication, and configurable recovery policies, protecting your business-critical applications from downtime and disasters. While SIOS Protection Suite can operate in a SAN environment to support a traditional HA hardware-based cluster, the architecture takes a shared-nothing approach to server clustering allowing it to run SANless. It delivers a robust, versatile and easily configurable solution with automatic and manual failover/failback recovery policies for a wide variety of applications.

SIOS Protection Suite for Linux includes:

  • SIOS LifeKeeper, which provides flexible failover clustering software that monitors the entire application stack
  • SIOS DataKeeper, which provides fast, efficient host-based, block-level data replication for mirroring local storage in a SANless cluster configuration or replicating to remote locations or cloud for disaster recovery
  • Multiple Application Recovery Kits (ARKs), with automated configuration and validation tools built into the product to protect your business-critical applications and data from downtime and disasters.

It is the SIOS’ team’s depth of knowledge in application recovery and the solution’s automation of application monitoring and recovery that makes it easier to use and a better, less expensive choice when compared to the Linux clustering solutions offered SUSE, Red Hat, and Oracle.

In addition, SIOS LifeKeeper supports all major Linux distributions, including Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS, and Oracle Linux and accommodates a wide range of storage architectures. SIOS software has been adapted and optimized to run on these operating systems and the components are tested so ensure the SANless cluster solution will work on each OS.

Lastly, with the SIOS Protection Suite for Linux, you can run your business-critical applications in a flexible, scalable cloud environment, such as Amazon Web Services (AWS) without sacrificing performance, high availability, or disaster protection.

Linux Clustering in AWS

While cloud providers, such as AWS, provide high availability options, they do not provide the level of high availability and breadth of protection across the whole application infrastructure that customers demand and that you once achieved by using clusters before cloud computing. That is why AWS is partnering with SIOS. SIOS Protection Suite for Linux achieves these desired levels of high availability for our mutual customers and the critical applications they are moving to the AWS cloud.

SIOS Protection Suite for Linux on AWS provides all the elements you need to create a high availability Linux cluster in a virtual private cloud (VPC) within a single AWS Region across two Availability Zones. It also supports out-of-the-box protection for SAP systems, Oracle databases, and other business-critical applications.

SIOS and AWS offer SIOS Protection Suite Quickstart on AWS, which helps you create a fully configured and operational Linux high availability cluster in a few short steps. It sets up an AWS architecture for SIOS Protection Suite for Linux and deploys it into your AWS account in about half an hour. This Quick Start, available in the AWS Marketplace, is for enterprise users who want to deploy SIOS Protection Suite for Linux on AWS into their test or production environment.

SIOS Clustering for Linux

SIOS is a high availability company that has spent the past 20 years focused on delivering HA that is specifically designed for SAP, SQL, Linux, Oracle, and other applications. Its experience is built into its product, and installation and configuration take a fraction of the time and cost when compared to custom scripting with the Linux distributions. In addition, SIOS tests and validates new versions of operating systems and applications so its customers don’t have to. When a customer calls SIOS for support, they are connected to a high availability expert – someone who only focuses on HA and has been doing so for a very long time.

For more information, refer to the SIOS white paper, “Implementing High Availability in a Linux Environment.”

Additional References

https://whatis.techtarget.com/definition/clustered-storage

Reproduced from SIOS

 
December 18, 2021

Failover Cluster

What is Failover?

The “Tell All” on Failover

Failover is the process by which a standby, redundant system, database, or network assumes operations when the primary system, database, or network fails, or primary operations are abnormally terminated. Hot failover is one of the key design principles incorporated into high availability and disaster recovery systems.

RTO is the maximum tolerable duration of any outage. Online transaction processing applications generally have the lowest RTOs, and those that are mission-critical often have an RTO of only a few seconds.

RPO is the maximum amount of data loss that can be tolerated when a failure happens. For HA, RPO is often zero to specify there should be zero data loss under all failure scenarios

Let’s Understand Failover

First, we need to discuss the difference between cold, warm, and hot standby servers:

  • A cold server (sometimes referred to as a cold failover) is one that is not connected to the primary server but is available and turned on only when the primary server goes down. With a cold server, it can take considerable time to power up the standby server, which may require an updated configuration and software. This means that Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) are the longest. Cold failover is considered unacceptable for mission-critical applications.
  • A warm server/failover is one that periodically receives updates from the primary server through data replication and mirroring.
  • A hot server/failover is one that receives regular updates from the primary server and is immediately available to take over in the event of a failover. Hot failover is the most resource-intensive, results in zero data loss (zero RPO) and RPOs of no more than a few minutes and is required to support high availability for mission-critical applications.

SIOS Failover Cluster Software supports hot failovers, delivering a zero RPO and an RTO of milliseconds for high availability. The results: a system failure results in no data loss and is transparent to the user.

SIOS Failover Cluster Software

SIOS offers failover cluster software so you can build a traditional shared storage cluster for high availability or a SIOS SANless cluster that uses local storage. SIOS software uses real-time synchronous (for LAN environments) or asynchronous (for WAN environments) data replication to synchronize storage.

SIOS solutions provide high availability and disaster recovery with a single solution. This approach eliminates the cost and complexity of SAN-based replication. With the ability to replicate to multiple targets, you can configure a multi-node failover cluster with nodes located in multiple locations to protect your systems from disasters.

With SIOS clusters, you can replicate between the configurations of your choice – between SAN and SANless environments and any combination of physical, virtual, cloud, and hybrid configurations. In fact, SIOS clustering solutions are unique in the breadth of operating systems, applications, and infrastructure environments supported, including Windows, Linux, SAP, SQL Server, Oracle, AWS, Azure, and Google cloud platforms.

SIOS failover
SIOS Failover Cluster Software uses efficient block-level replication to keep local storage synchronized, enabling the secondary nodes in your cluster to continue to operate after a failover with access to the most recent data.

In a Windows environment, SIOS DataKeeper gives you the flexibility to build a Windows cluster in any combination of physical, virtual, and cloud environments. SIOS DataKeeper Cluster Edition seamlessly integrates with and extends Windows Server Failover Clustering (WSFC) by providing a performance-optimized, host-based data replication mechanism.

In a Linux environment, SIOS LifeKeeper and SIOS DataKeeper provide a tightly integrated combination of high availability failover clustering, continuous application monitoring, data replication, and configurable recovery policies, protecting your business-critical applications from downtime and disasters.

 

Let’s review one case study that talks to the benefits of one of SIOS’ solutions – SIOS DataKeeper.

A SIOS Failover Cluster Software Solution in Action

Located in The Netherlands, Van de Lande BR (VDL) manufactures a wide range of PVC and PE compression fittings and valves. Their products are used all over the world in industrial and technical installations. Manufacturing more than 4500 different products, VDL is deeply committed to product improvement and quality, making their brand the choice for builders of systems and installations for more than 50 years.

VDL has a Hyper-V environment, solid state disk (SSD) storage, and its business relies heavily on its ERP solution. With only one data processing system in place, VDL was exposed and needed a disaster recovery (DR) solution to ensure the protection and availability of its ERP, web services, and other mission-critical systems in the event of a disaster.

To deliver immediate failover and DR protection, VDL built a Windows Server Failover Clustering (WSFC) system, with one node replicating data to the other node. If the primary node fails, WSFC transfers all operations to the standby node, giving users continuous access to applications and data.

VDL also chose SIOS DataKeeper Cluster Edition to provide DR for its Hyper-V virtual machines (VM). SIOS DataKeeper is a software add-on that provides uninterrupted data access. It seamlessly integrates with WSFC to add performance-optimized, host-based, synchronous or asynchronous real-time replication of Hyper-V VMs between physical servers across both LAN and WAN connections. Working with WSFC, SIOS DataKeeper monitors the system and application health, maintains client connectivity, and makes it possible to create SANless clusters. Unlike a SAN, a SANless cluster eliminates single points of failure and reduces the cost and complexity of deploying clusters.

SIOS DataKeeper also uses WSFC to provide system administrators with a familiar and application-agnostic HA/DR solution, thereby dramatically simplifying implementation and operation.

VDL deployed two SIOS DataKeeper clusters; one two-node cluster works as a file server and iSCSI server while the other supports a SQL Server (ERP) cluster and Dynamics NAV web services. The implementation took less than one day. During the system failover test, the network services team failed over and failed back the system quickly and easily. After a thorough evaluation of the VDL server configuration and the completion of testing, the installation team confirmed that SIOS DataKeeper and a SANless cluster met all their criteria for disaster recovery, performance, and high availability of their ERP system, web services, and other mission-critical applications. The organization no longer risks data loss in the event of a failure.

One Last Thing

In addition to testing SIOS, VDL tested other solutions with unacceptable results. Comments Maurits van de Lande, ICT Manager at VDL, “We have tested our file server with both DFS replication and AlwaysOn technology. Neither delivered an automated disaster recovery solution to match SIOS DataKeeper, which fully addresses our DR requirements.”

———————————————————————————————————————————-

Regardless of your IT environment, your organization can reap the benefits of SIOS DataKeeper Cluster Edition and DataKeeper Standard Edition, both of which provide configuration flexibility, reduce data transfer costs, eliminate single points of failure, reduce complexities, and optimize network performance.

For more information, contact us or request a free trial.

References:

Reproduced from SIOS

 
December 13, 2021

Data Replication

 

 

Data Replication

Real-Time Data Replication for High Availability

What is Data Replication

Data replication is the process by which data residing on a physical/virtual server(s) or cloud instance (primary instance) is continuously replicated or copied to a secondary server(s) or cloud instance (standby instance). Organizations replicate data to support high availability, backup, and/or disaster recovery.  Depending on the location of the secondary instance, data is either synchronously or asynchronously replicated. How the data is replicated impacts Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPO).

For example, if you need to recover from a system failure, your standby instance should be on your local area network (LAN). For critical database applications, you can then replicate data synchronously from the primary instance across the LAN to the secondary instance. This makes your standby instance “hot” and in sync with your active instance, so it is ready to take over immediately in the event of a failure. This is referred to as high availability (HA).

In the event of a disaster, you want to be sure that your secondary instance is not co-located with your primary instance. This means you want your secondary instance in a geographic site away from the primary instance or in a cloud instance connected via a WAN. To avoid negatively impacting throughput performance, data replication on a WAN is asynchronous. This means that updates to standby instances will lag updates made to the active instance, resulting in a delay during the recovery process.

Why Replicate Data to the Cloud?

There are five reasons why you want to replicate your data to the cloud.

  1. As we discussed above, cloud replication keeps your data offsite and away from the company’s site. While a major disaster, such as a fire, flood, storm, etc., can devastate your primary instance, your secondary instance is safe in the cloud and can be used to recover the data and applications impacted by the disaster.
  2. Cloud replication is less expensive than replicating data to your own data center. You can eliminate the costs associated with maintaining a secondary data center, including the hardware, maintenance, and support costs.
  3. For smaller businesses, replicating data to the cloud can be more secure especially if you do not have security expertise on staff. Both the physical and network security provided by cloud providers is unmatched.
  4. Replicating data to the cloud provides on-demand scalability. As your business grows or contracts, you do not need to invest in additional hardware to support your secondary instance or have that hardware sit idle if business slows down. You also have no long-term contracts.
  5. When replicating data to the cloud, you have many geographic choices, including having a cloud instance in the next city, across the country, or in another country as your business dictates.

Why Replicate Data Between Cloud Instances?

While cloud providers take every precaution to ensure 100 percent up-time, it is possible for individual cloud servers to fail as a result of physical damage to the hardware and software glitches – all the same reasons why on-premises hardware would fail. For this reason, organizations that run their mission-critical applications in the cloud should replicate their cloud data to support high availability and disaster recovery. You can replicate data between availability zones in a single region, between regions in the cloud, between different cloud platforms, to on-premise systems, or any hybrid combination.

SIOS Real-Time Data Replication for High Availability and Disaster Recovery

SIOS Datakeeper™ uses efficient, block-level, data replication to keep your primary and secondary instances synchronized. If a failover happens, the secondary instance(s) continues to operate, providing users with access to the most recent data. With SIOS solutions, RPO is always zero and RTO is dependent on the application but typically 30 seconds to a few minutes.

SIOS products uniquely protect any Windows- or Linux-based application operating in physical, virtual, cloud or hybrid cloud environments and in any combination of site or disaster recovery scenarios, enabling high availability and disaster recovery for applications such as SAP and databases, including Oracle, HANA, MaxDB, SQL Server, DB2, and many others. The “out-of-the-box” simplicity, configuration flexibility, reliability, performance, and cost-effectiveness of SIOS products set them apart from other clustering software.

In a Windows environment, SIOS DataKeeper Cluster Edition seamlessly integrates with and extends Windows Server Failover Clustering (WSFC) by providing a performance-optimized, host-based data replication mechanism. While WSFC manages the software cluster, SIOS performs the data replication to enable disaster protection and ensure zero data loss in cases where shared storage clusters are impossible or impractical, such as in cloud, virtual, and high-performance storage environments.

In a Linux environment, SIOS LifeKeeper and SIOS DataKeeper provide a tightly integrated combination of high availability failover clustering, continuous application monitoring, data replication, and configurable recovery policies, protecting your business-critical applications from downtime and disasters.

———————————————————————————————————————————

Here is a real-world example of how one leading manufacturing company uses SIOS to create a high availability solution in the cloud using real-time data replication.

How to Achieve HA in a Cloud Environment with Real-Time Data Replication

Bonfiglioli is a leading Italian design, manufacturing, and distribution company, specializing in industrial automation, mobile machinery, and wind energy products and employing over 3,600 employees in locations around the globe. To run its business, the company relies on various mission-critical applications, including its SAP ERP system. The company’s IT infrastructure includes an on-premises VMware data center and a remote data center for business continuity and disaster protection. Since most of their applications run in a Windows environment, Bonfiglioli used guest-level Windows Server failover clustering in their VMware environment to provide high availability and disaster protection.

The company’s IT team implemented a program to move part of its IT operations into the Microsoft Azure cloud and to leverage Azure as their disaster recovery site. An important requirement of the company’s migration plan was to ensure the cloud architecture could provide better high availability protection than before and ensure Bonfiglioli could continue to meet its strict Service Level Agreements (SLAs).

In its on-premises environment, the company uses VMware clustering, which allows Windows Server Failover Clustering (WSFC) to manage failover to a secondary server in the event of an infrastructure failure. However, it was a challenge to provide this type of protection in the cloud because using guest-clustering with shared-bus disks is not a viable cloud solution. Creating a cluster in VMware using Raw Device Mapping and shared-bus disks (RDM) is challenging and creates limitations for backing up the virtual machines.

The Solution

After evaluating several solutions, Bonfiglioli chose SIOS DataKeeper as their cloud high availability and disaster recovery solution upon learning that SIOS DataKeeper is the only certified high availability clustering solution for SAP in a public cloud. In addition, Bonfiglioli’s management consulting partner, BGP, had experience with SIOS DataKeeper and knew that it is easy to install, transparent to the operating system, and a proven, highly effective solution.

With SIOS, the IT team fashioned a cluster environment without RDM. They created a two-node cluster in VMware and added SIOS DataKeeper Cluster Edition to synchronize storage via real-time data replication in each cluster instance. In an on-premises environment, synchronized storage appears to WSFC as a single shared storage disk.

SIOS DataKeeper also provides high availability protection for the company’s SAP instance and eliminates single point of failure. Using SIOS DataKeeper, the IT team replicated an SSD-tiered disk partition in the company’s on-premises data center using real-time data replication. This allows Bonfiglioli to restore their virtual machines to Microsoft Azure in the event of a disaster.

The Results

Daniele Bovina, Systems Architect at Bonfiglioli, comments about the results, “SIOS DataKeeper gave us an easy way to move our business-critical SAP system to the Microsoft Azure cloud while meeting our stringent SLAs for availability, disaster recovery, and performance.”

—————————————————————————————————————————–

For more information about SIOS Clustering Solutions, contact us or request a free trial.

References

Reproduced from SIOS
  • Results 226-230 of 936
  • < Page 46 of 188 >

  • Join Our Mailing List