SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Minimizing Downtime with High Availability

by Leave a Comment

Minimizing Downtime with High Availability

Minimizing Downtime with High Availability

Downtime has become more costly than ever before for modern businesses. The ITIC 2021 Hourly Cost of Downtime Survey found that in 91% of organizations, one hour of downtime in a business-critical system, database, or application costs an average of more than $300,000, and for 18% of large enterprises, the cost of an hour of downtime exceeds $5 million.

High availability (HA) is an attribute of a system, database, or application that’s designed to operate continuously and reliably for extended periods. The goal of HA is to reduce or eliminate unplanned downtime for critical applications. This is achieved by eliminating single points of failure by incorporating redundant components and other technologies in the design of a business-critical system, database, or application.

SLAs and HA Metrics

Service-level agreements (SLAs) are used by service providers to guarantee that a customer’s business-critical systems, databases, or applications are up and running when the business needs them.

IDC has created an SLA model that defines uptime requirements at five levels as follows:

  • AL4 (Continuous Availability – System Fault Tolerance): No more than 5 minutes and 15 seconds of planned and unplanned downtime per year (99.999% or “five-nines” availability)
  • AL3 (High Availability – Traditional Clustering): No more than 52 minutes and 35 seconds of planned and unplanned downtime per year (99.99% or “four-nines” availability)
  • AL2 (Recovery – Data Replication and Backup): No more than 8 hours, 45 minutes, and 56 seconds of planned and unplanned downtime per year (99.9% or “three-nines” availability)
  • AL1 (Reliability – Hot Swappable Components): No more than 87 hours, 39 minutes, and 29 seconds of planned and unplanned downtime per year (99% or “two-nines” availability)
  • AL0 (Unprotected Servers): No availability or uptime guarantee

 According to ITIC, 89% of surveyed organizations now require “four-nines” availability for their business-critical systems, databases, and applications, and 35% of those organizations further endeavor to achieve “five-nines” availability.

In addition to uptime and availability, two other important HA metrics are Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). RTO is the maximum tolerable duration of any outage and RPO is the maximum amount of data loss that can be tolerated when a failure happens. Unlike RTO and RPO metrics for disaster recovery which are typically defined in hours and days, RTO and RPO metrics for business-critical systems, databases, and applications are often only a few seconds (RTO) and zero (RPO).

HA Clustering

HA clustering typically consists of server nodes, storage, and clustering software.

Traditional Clustering

A traditional, on-premises HA cluster is a group of two or more server nodes connected to shared storage (typically, a storage area network, or SAN) that are configured with the same operating system, databases, and applications (see Figure 1).

Traditional server clustering with shared storage
Figure 1: Traditional server clustering with shared storage

One of the nodes is designated as the primary (or active) node and the other(s) are designated as secondary (or standby) nodes. If the primary node fails, clustering allows a system, database, or application to automatically fail over to one or more secondary nodes and continue operating with minimal disruption. Since the secondary node is connected to the same storage, operation continues with zero data loss.

However, the use of shared storage in the traditional clustering model creates several challenges, including:

  • The shared storage itself is a single point of failure that can potentially take all of the connected nodes in the cluster offline.
  • SAN storage can also be costly and complex to own and manage.
  • Shared storage in the cloud can add significant, unnecessary cost and complexity and some cloud providers don’t even offer a shared storage option.

SANless Clustering

SANless or “shared nothing” clusters (see Figure 2) address the challenges associated with shared storage. In these configurations, every cluster node has its own local storage. Efficient host-based, block-level replication is used to synchronize storage on the cluster nodes, keeping them identical. In the event of a failover, secondary nodes access an identical copy of the storage used by the primary node.

HA clustering with SANless or “shared-nothing” storage
Figure 2: HA clustering with SANless or “shared-nothing” storage

Clustering Software

Clustering software lets you configure your servers as a cluster so that multiple servers can work together to provide HA and prevent data loss. A variety of clustering software solutions are available for Windows, Linux distributions, and various virtual machine hypervisors. However, each of these solutions limits your flexibility and deployment options and introduces various challenges such as technical complexity and expensive licensing.

Don’t Wait for Disaster to Strike

HA is crucial for business-critical systems, databases, and applications. But with the myriad platforms available, complexity ramps up significantly. That’s why an application-aware solution makes so much sense. What you need is a trusted partner who has extensive expertise in high availability—a partner like SIOS, which has the technological know-how to ensure that your business stays up and running.

Don’t wait for an outage or disaster to find out if you have the resiliency your business needs. Schedule a personalized demo today at https://us.sios.com to see what SIOS can do for your business.

Reproduced from SIOS

Fixing Your Cloud Journey

by Leave a Comment

Fixing Your Cloud Journey

Fixing Your Cloud Journey

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.

  1. Add high availability

    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:

    • Designing and architecting a highly available and redundant architecture
    • Choosing software and services that will protect critical components and applications
    • Defining and documenting associated processes and procedures, and at least a minimal governance
    • Deploying production copies for quality assurance, procedural testing, and chaos testing

  2. Expand for higher availability for disaster recovery

    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.

  3. Build your team

    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:

    • Adding capacity.  Unless you were able to pull off a complete lift and shift, you likely have the same staff managing cloud and on-premises applications.  Legacy solutions are known for being temperamental and requiring a lot of work to keep them stable and available.To navigate the cloud journey ahead you’ll need capacity capable of addressing availability requirements, understanding cloud architecture, and plotting the course forward for enterprise needs.
    • Augmenting skills with training.  Give your team training for the cloud.  To manage and plan the course forward, look for ways to augment the IT excellence within your organization with additional training on cloud solutions, architecture, best practices, and trade-offs.  A confidently trained staff will not only pay dividends in increased availability, but they will also pay dividends by addressing availability, maintenance, and growth in an economic, scalable and logical way.  Translation: they’ll avoid wasting money as they build out the rest of your cloud infrastructure.

  4. Integrating automation and analytics

    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.

  5. Update processes and governance

    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

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

by Leave a Comment

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

Data Replication

by Leave a Comment

 

 

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

Achieving IT Resilience with High Availability

by Leave a Comment

Achieving IT Resilience with High Availability

Achieving IT Resilience with High Availability

What is IT Resilience?

IT resilience is the ability of an organization to maintain acceptable service levels when there is a disruption of business operations, critical processes, or your IT ecosystem. In this digital age, high availability is critical to your organization’s success. Your customers won’t tolerate a downed website. And you cannot afford a downed ERP, CRM, or other business-critical system either. This is where high availability comes in.

Your organization must “check the boxes” on many different technologies and solutions to ensure IT resiliency – not the least among them is ensuring, at a minimum, that you have backup, disaster recovery, cyber resilience, and high availability solutions in place. For purposes of this article, we will be talking about high availability (HA) as one of the key elements required to ensure IT resiliency.

What is High Availability?

High availability systems ensure that business operations continue – with total transparency to customers and users – when your system, applications, and network goes down. HA is a component of a technology system that eliminates single points of failure to ensure continuous operations or uptime for an extended period. Highly available systems incorporate five design principles: automatic failover, automatic detection of application-level failures, no data loss, automatic and quick fail over to redundant components, and push-button failover and failback for planned maintenance.

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

IT Resilience and High Availability – A Non-Example!

This past August, Nissan Group’s data center in Denver crashed because of a power outage. The system impacted was known internally as NNANet. It is a Nissan solution used by employees to order cars/parts, manage product rebate sales, get info on vehicle recalls, file warranty claims needed to price and start service work, and getting financing information.  NNANet is described as Nissan’s lifeblood because everything Nissan does goes through NNANet.

The system remained down for four days, impacting operations at many retailers and production systems at two factories. The company, its retailers, and customers were all impacted.

The Impact

Clearly, this is an example where correctly configured, properly located high availability systems would have saved the day or at least minimized the impact of the crash. What was a high availability situation literally turned in to a disaster for Nissan as “commerce among consumers, retailers, distribution networks, manufacturing plants and finance companies.” were all affected for four days.[1] Nissan reset dealer sales goals by 10 percent for the month as a result of the crash. The total financial impact for Nissan and its dealers/retailers/partners remains to be seen.

IT Resilience– A Real-World Example!

Cayan™ is the leading provider of payment technologies and its Genius Customer Engagement Platform® aggregates and integrates every conceivable transaction technology, payment type, and customer program – both present and future – into a single platform. The Genius platform, as well as other mission-critical applications at Cayan, run on SQL Server.

Cayan customers include some of the world’s largest online retailers, companies with no tolerance for downtime. “Our top priority is ensuring that our customers can complete transactions continuously 24 hours a day, seven days a week,” said Paul Vienneau, Chief Technology Officer, Cayan.

Cayan needed a high availability and disaster recovery system for their SQL Server database. The company considered a traditional shared storage cluster, but a SAN solution was expensive, complicated to manage, and introduced risk associated with a single point of failure.

For these reasons, Cayan IT staff decided to use SIOS #SANLess clusters. SANLess clusters use local storage so there is minimal performance overhead and fast application response times. The SIOS software, SIOS DataKeeper, is integrated with Windows Server Failover Clustering (WSFC). SIOS uses efficient, real-time, data replication to synchronize local storage in the primary and remote cluster nodes, making them appear to WSFC as a virtual SAN.

The Impact

Since deploying SIOS SANless clusters, Cayan has not experienced any downtime or data loss. Comments Paul Vienneau, CTO, “We are very pleased with the SIOS DataKeeper software. It met or exceeded our expectations. Implementation and ongoing administration were easy, and we have had zero downtime since we implemented our SIOS SANLess clusters.”

There are no customer satisfaction issues to report, no lost revenues, no unproductive employees, no disruption to the business.

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

SIOS: Achieve IT Resilience with High Availability

SIOS DataKeeper™ 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.

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 S/4HANA and databases, including Oracle, 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 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 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.

Whether you are in a Windows or Linux environment, SIOS products free your IT team from the complexity and challenges of creating and managing high availability computing infrastructures. They provide the intelligence, automation, flexibility, high availability, and ease-of-use IT managers need to protect business-critical applications from downtime or data loss.

SIOS = IT Resilience with HA + DR

Backup, high availability, disaster recovery, and cyber resilience are all important elements in achieving IT resilience. With SIOS solutions, you can “check the box” for both high availability and disaster recovery – two solutions in one. 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 failures and disasters.

For more information, and to ensure IT resilience for your organization, get a free demo of SIOS today.

References:

Reproduced with permission from SIOS