SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

SIOS DataKeeper Adds High Availability Protection To Cluster

by Leave a Comment

SIOS DataKeeper Adds High Availability Protection To Cluster.png

Healthcare Platform Eliminated Need For Shared Storage with SIOS DataKeeper Cluster Edition

Case Study: Leading Healthcare Provider — SIOS DataKeeper Cluster Edition

A leading provider of enterprise platforms for the home healthcare provider market decided to add SIOS DataKeeper Cluster Edition as a high availability (HA) solution to minimize the risk of downtime. It had relied on its SQL Server databases to provide fast, efficient service to its end users.

Many of the company’s important applications rely on SQL Server running on a physical server in their on-premises data center. They wanted to protect their SQL Server Replication Distributor – a central database required for managing and updating all SQL databases.

The company’s best solution was to use Windows Server Failover Clustering to create a two node cluster using their existing server hardware, which was already equipped with solid state disk storage. By adding SIOS DataKeeper Cluster Edition software to their cluster, they eliminated the need for shared storage. SIOS software uses fast block level replication to synchronize local storage in both of the cluster nodes, creating a storage environment that appears to WSFC as a SAN. They connected the nodes directly using crossover cables and 10Gig NICs to eliminate the cost of a network switch and ensure the fastest possible replication for real time synchronization of the cluster nodes.

High Availability Clustering Solution for Point of Sale Server Systems

by Leave a Comment

Migros implemented SIOS Protection Suite high-availability clustering solution to constantly monitor their POS server systems

Case Study: Migros — SIOS DataKeeper Clusters

The Swiss supermarket giant achieves critical business continuity with SIOS Data Replication Solutions. SIOS software replication secured the data generated by the monitoring software. SIOS Protection Suite software provides continuous monitoring of servers, storage, applications, databases and network connections to detect points of failure. The high-availability clustering solution aims to reduce planned and unplanned downtime, maintain client connectivity and provide uninterrupted data access.

High Availability for Global Retailer’s Mission-Critical Systems

by Leave a Comment

High Availability for Global Retailer’s Mission-Critical Systems To Eliminate Risks

Case Study: High Availability for Global Retailer’s Mission-Critical Systems

By adding SIOS DataKeeper Cluster Edition to a Windows Server Failover Clustering environment in the Amazon Web Services cloud, this global retailer migrated a complex infrastructure into a high availability cluster in the cloud easily and without any downtime.

SIOS DataKeeper Cluster Edition provided the retailer the high-availability protection they needed and eliminated the risks associated with a single point of failure in shared storage SAN cluster configurations. The SIOS failover process enabled automatic system and application recovery and prevented data loss if a server goes down, allowing the retailer’s customers to shop and place orders online safely without any interruptions.

Clustering SAP ASCS Instance On Azure

by Leave a Comment

Clustering SAP ASCS Instance On Azure

Microsoft published a blog post and white paper on clustering SAP ASCS instance using Windows Server Failover Cluster on Microsoft Azure public cloud. It describes how to install and configure a high-availability (HA) SAP central services instance ASCS in a Windows Server Failover Cluster (WSFC) using the platform Microsoft Azure.

Download the white paper here http://go.microsoft.com/fwlink/?LinkId=613056

Reproduced with permission from https://clusteringformeremortals.com/2015/06/05/clustering-sap-ascs-instance-on-azure/

Why Build A SQL server Failover Cluster Instance In Azure Cloud?

by Leave a Comment

Why Would You Want To Build A SQL server Failover Cluster Instance In The Azure Cloud?

There was an interesting discussion happening today in the Twitterverse. Basically, someone asked the question “Has anyone set up a SQL server Failover Cluster Instance in Azure?” The ensuing conversation involved some well respect SQL Server experts. And it led to the following question, “Why would you want to build a SQL Server AlwaysOn Failover Cluster instance in the cloud?”

That question could be interpreted in two ways: “Why do you need High Availability in the Cloud” or “Why wouldn’t you use AlwaysOn Availability Groups instead of Failover Cluster Instances?”

Let’s address each question one at a time.

Question 1 – Why do you need High Availability in the Azure Cloud?

  • You might think that just because you host your SQL Server instance in Azure, that you are covered by their 99.95% uptime SLA. If you think that, you would be wrong. In order to take advantage of the 99.95% SLA, you have to have at least two instances of SQL running in an Availability Set. With a single instance of SQL running, you can definitely expect that there will minimally be downtime during maintenance periods. But, you are also susceptible to unplanned failures.
  • Two instances of SQL Server cannot generally be load balanced. You have to implement some sort of mechanism to keep the servers in sync. To ensure that if there is a problem with one of the servers, the other server will be able to continue to service the requests. High Availability solutions like AlwaysOn Availability Groups, AlwaysOn Failover Cluster Instances and even the deprecated Database Mirroring can provide high availability for SQL Server in that scenario. Other solutions like log shipping and transactional replication may be able to help keep data synchronized between servers. But they are not typically considered high availability solutions and will not ensure the availability of your SQL Server.
  • Microsoft does occasionally need to perform maintenance on Azure that could bring down an entire Upgrade Domain and all the instances running in that Upgrade Domain. You don’t have any say on when this will happen. So, you need to have a mechanism in place to ensure that if they do have to bring down your primary SQL Server instance, you can expect that your secondary SQL Server instance will take over the workload without missing a beat. All of the high availability solutions mentioned above can ensure that you will continue to run in the event that Microsoft is doing maintenance on the Upgrade Domain of your primary server. Microsoft will only do maintenance on a single Upgrade Domain at a time. This ensures that your secondary server will still be online assuming you put the both in the same Availability Set.
  • What do you do if YOU want to performance maintenance on your production SQL Server? Maybe you want to install a Service Pack or other hotfix? Without a secondary server to fail over to, you will have to schedule planned downtime. One of the primary benefits of any high availability solution is the ability to do rolling upgrades, minimizing the impact of planned downtime.

Question 2 – Why wouldn’t you use AlwaysOn Availability Groups instead of Failover Cluster Instances?

  • Save Money! SQL Server AlwaysOn Availability Groups requires Enterprise Edition of SQL Server. Why not save money and deploy SQL Server Standard Edition and build a simple 2-node Failover Cluster Instance? Unless you need Enterprise Edition for some other reason, this is a no brainer.
  • Protect the ENTIRE SQL Server instance. AlwaysOn Availability Groups only protects user defined databases; you cannot protect the System and MSDB databases. If you build a SQL Server Failover Cluster Instance instead, you are protecting the ENTIRE instance, including the System and MSDB databases.
  • Ease Administration. In Azure, you are limited to just on client listener. This limits you to just one Availability Group. In contrast, with a Failover Cluster Instance one client listener is all you need, so there is no limitation.
  • Worker Thread Exhaustion. With AlwaysOn AG, you have to keep an eye on the available worker threads. The available worker threads limit the number of databases you can protect with AlwaysOn AG. In contrast, AlwaysOn Failover Clustering with DataKeeper block level replication does not consume more resources for each database you add. This means you can scale to protect hundreds of databases without the additional overhead associated with AlwaysOn AG.
  • Distribute Transaction Support. AlwaysOn AG does not support distributed transactions (DTC). If your application requires DTC support, you are going to have to look at an AlwaysOn Failover Cluster Instance instead.
  • Support of Other Replication Technologies. If you plan on setting up Peer to Peer replication between two databases protected by AlwaysOn AG you can forget about it. In fact, there are many restrictions you have to be aware of once you deploy AlwaysOn Availability Groups. AlwaysOn FCI’s do not have any of those restrictions.

Conclusion

Knowing what you know above, shouldn’t the question really be “Why would I want to implement AlwaysOn AG in the Cloud when I can have a much more robust and inexpensive solution building an AlwaysOn Failover Cluster instance?”

If you are interested in building an AlwaysOn Failover Cluster Instance in Azure, check out my blog post Step-by-Step: How to configure a SQL Server Failover Cluster Instance (FCI) in Microsoft Azure IaaS #SQLServer #Azure #SANLess

Reproduced with permission from https://clusteringformeremortals.com/2015/03/05/why-would-you-want-to-build-a-sqlserver-failover-cluster-instance-in-the-azure-cloud/