failover clustering | SIOS SANless clusters

Webinar: Failover Clustering in the Cloud – Understanding Your Options

May 24, 2019 by Jason Aw Leave a Comment

Failover Clustering in the Cloud – Understanding Your Options

Webinar: Failover Clustering in the Cloud – Understanding Your Options

Windows Server 2016 introduced Storage Spaces Direct, to allow for shared storage in Azure that could help with building and configuring a Windows cluster in the cloud. While this sounded like a killer feature (and it can be with proper infrastructure) it runs into challenges in cloud environments with limited bandwidth available for both storage and data traffic.

In this webinar, you will learn about the configuration of clusters in the cloud, some real-world examples of problems, and alternatives for maintaining a shared storage infrastructure within Azure.

Register Webinar: Failover Clustering in the Cloud – Understanding Your Options

Data Protection and Failover Clustering During Migration To Cloud

May 29, 2018 by Jason Aw Leave a Comment

Migrate Existing System Running SQL Server And WSFC Configuration To Cloud With SIOS For Data Protection and Failover Clustering

Gulliver is pursuing to migrate their existing on-premises systems to cloud. For this project, they picked SIOS Data keeper to ensure real-time replication, data protection and failover clustering.

The company aimed to build an IT infrastructure capable of responding swiftly and flexibly to the growth of these businesses. Protection of important data is essential as they shift to the cloud.

The system owned by Gulliver included the used car sale system “Dolphinet”. Most parts of this system has been built and operated on physical servers in their data center. Therefore, reform is definitely in their pipeline to achieve the expansion goal of 1,600 global stores.

Full Transition From On-Premise To Cloud

IT Team Tsukishima School said that for Gulliver, IT is the core of the business. Thus, having a strong and secure IT foundation would allow the company respond to rapid business expansion. Since 2011, the company has been contemplating a full-scale system migration to the AWS cloud service. Their entire operation can be controlled in the cloud which is easy and fast.

Challenges Faced in Migrating to the Cloud

Many of Gulliver’s systems are constructed with Microsoft products such as Windows Server, SQL Server of relational database, IIS (Internet Information Services) of Web server, .NET Framework of application development and execution environment.

The first challenge in transitioning to the cloud is the question of how to implement these platforms in AWS.

“We initially considered utilizing the SQL Server function supported by RDS (Relational Database Service), but we are also trying to use redundant (clustering) important systems and user management (Active Directory link) We did not have all the necessary functions yet. So, we considered other methods but the risks were too many many and too huge to undertake.”

Redundancy Plan To Ensure High Availability

So Gulliver chose to use the virtual server’s Amazon Elastic Compute Cloud (Amazon EC 2) natively. The existing environment including the failover clustering (WSFC) function of Windows Server running on-premises is used directly. Therefore, DataKeeper played an important role in synchronizing the data of the existing environment as it is.

Achieve Real-Time Data Protection Without Using Shared Storage

DataKeeper performs data replication in real time between the production node and the standby node and protects data until just before the failure occurs. Compared to the general storage mirroring function, volume mirroring is realized at low cost. It can be utilized according to various needs such as the system configuration and the importance of data and the necessity of measures against disaster recovery (DR).

Simple HA Cluster Without Using Shared Storage On AWS

It is advantageous to be able to have HA cluster system (application protection configuration) without using external shared storage premised on failover clustering like WSFC. This is the point where Gulliver chose to adopt DataKeeper for Data Protection and Failover Clustering.

Gulliver’s Tsukishima said, “I was surprised that DataKeeper looks as if it is sharing storage from WSFC. The speed of mirroring is good. When an abnormality happens in HA cluster operation, I am extremely satisfied that it is easy to isolate and deal with. Whether it is on the clustering (WSFC) side or the data replication (DataKeeper) side, it becomes a quick and fuss free process. This point applies even when we are configuring the physical server. It became possible to shift to AWS without changing the operation form of the existing system at all. ”

Gulliver intends to move on to the rest of the existing system by 2014. At the same time, it is implementing the newly developed system in AWS.

To find out more about SIOS products, go here
To read about how SIOS helped Gulliver achieve data protection and failover clustering in their cloud migration go here

Learn Windows Server 2012 R2 Failover Clustering

March 12, 2018 by Jason Aw Leave a Comment

Learn Windows Server 2012 R2 Failover Clustering – Microsoft Virtual Academy

For those who have never been exposed to clustering or just new to clustering in Windows Server 2012 R2, this is the class for you. Symon Perriman (@SymonPerriman), 5nine Software Vice President of Business Development and Elden Christensen, Microsoft Principal Program Manager Lead, live and breathe failover clustering. With such great knowledgeable instructors, this two men would definitely be able to give you some great ideas on your next project or simply give you an alternative view. You can’t ask for any better instructors. Stop what you are doing and watch this RIGHT NOW!

http://www.microsoftvirtualacademy.com/training-courses/failover-clustering-in-windows-server-2012-r2

Reproduced with permission from https://clusteringformeremortals.com/2015/02/12/learn-windows-server-2012-r2-failover-clustering-microsoft-virtual-academy/

Overcoming Performance Issues With SQL Server Alwayson Availability Groups

February 5, 2018 by Jason Aw Leave a Comment

Asynchronous vs synchronous replication on AlwaysOn

From attending the sessions at PASS Summit this week, it has become obvious that AlwaysOn is a hot topic with about six sessions dedicated to this solution . The one thing that I learned is that although the solution certainly has its applications, most of the successful deployments are based on using AlwaysOn in an asynchronous fashion. The reason people avoid the synchronous replication option is that the overhead is too great. During synchronous replication any write must be committed on the replica before it is committed on the source. In the testing that I have done, this overhead introduced can be as much as 68%.

For example, in a test where I have a database inserting about 1,000,000 rows per second and we measure the throughput on the log file, we see that with no mirroring in place we are writing about 400 MBps. Once we start replicating that database with AlwaysOn Availability Groups across a 10 Gbps LAN, we see about a 68% drop off in performance, with this particular database slowing down to about 250,000 inserts per second.

Asynchronous vs synchronous replication on AlwaysOn — Figure 1 – MBps written to a SQL Server database before and after AlwaysOn Synchronous Mirroring

If you are considering the solution as a replacement to your failover cluster, this drop off should be of a major concern to you. In order to achieve the automatic failover that you are accustomed to in failover clustering, you must use synchronous mirroring, which means that you must live with this performance hit. Generally this is not going to be acceptable, which is probably why you don’t hear the experts recommending such configurations on a regular basis.

So what should you do?

Should you stick with you traditional failover cluster and a SAN? What if you want to take advantage of fast, high speed storage such as Fusion-io? In that case, you can’t use a traditional cluster…or can you?

The good news is that you can build a cluster without a SAN and do it all without the expense, limitations and overhead associate with AlwaysOn Availability Groups (more on the limitations and expense in my next blog post). By using DataKeeper Cluster Edition you can build clusters without shared storage AND the overhead associated with Synchronous replication is closer to 10% vs. the close to 70% we see with AlwaysOn Availability Groups.

Come to booth 351 at #SQLPASS and I’ll be glad to demonstrate how the solution works.

Reproduced with permission from https://clusteringformeremortals.com/2012/11/09/how-to-overcome-the-performance-problems-with-sql-server-alwayson-availability-groups-sqlpass/

New Features of Windows Server Failover Clustering

February 3, 2018 by Jason Aw Leave a Comment

New Features of Windows Server Failover Clustering

Elden Christensen recently blogged about some of the new features of Windows Server Failover Clustering in Windows Server 8. You can read the entire post here

All of these features found in Windows Server Failover Clustering in Windows Server 8 are welcome additions. My personal favorite is the “Dynamic Clusters” or what I think is probably better described as “Dynamic Quorum”. It basically allows the quorum to reconfigure itself dynamically which I think is a fantastic feature! If configured properly, you could actually withstand the failure of all but one remain node (last man standing) and still have a functional cluster. Previously this was only possible if you used the “Disk Only” quorum model, which is not recommended as the disk quorum represented a single point of failure.

With the new dynamic quorum model as nodes are removed from the cluster, the remaining nodes reconfigure themselves in the most resilient manner. For example, previously you had a 5 node cluster using the “Node Majority” quorum model. If you lose three nodes, the remaining two nodes would shut down as they no longer had a majority vote (2 out of 5 is not a majority). With the new model, as nodes leave the cluster, the quorum reconfigures itself so that the remaining two nodes would remain online.

The description above is really an over simplification of what actually happens under the covers. I plan to write more about it in the future, but it is definitely a welcome feature to check out!