xkoto Gridscale: A better way to cluster MS SQL?
If you've ever tried to implement a MS SQL server cluster then you're familiar with the quorum drive concept and how it is used for clustering. Microsoft's NTFS is a single instance filesystem that does not have a clustering component. While there are replacements for NTFS like HP's Polyserve cluster filesystem product, I recently uncovered xkoto Gridscale. xkoto's Gridscale for MS SQL is a very different approach to clustering. I was fortunate enough to have a brief technical discussion with one of their engineers the other day and here's the short version of his explanation of Gridscale. The Gridscale product claims to avoid the scalability limitations, technical complexity, and costs associated with traditional clustering, mirroring and replication solutions for SQL Server by assisting you to scale application load horizontally across multiple, active-active instances of SQL Server. Also, you can eliminate planned and unplanned database outages since all SQL Servers managed by Gridscale are fully active. Finally, since Gridscale supports databases in remote locations, you can meet disaster recovery requirements without the complexity of traditional transaction-based (journaling) or storage replication solutions.
Ok, so this begs the obvious question: How does this work? Well, Gridscale runs on a pair of gateway (my term, not theirs) servers (active/passive). These gateway servers run between your applications and databases (see the image above this post) to manage multiple, active-active copies of SQL Server databases running anywhere on the network. Gridscale then load balances read requests, while write requests and database changes are propagated asynchronously to all databases to keep them in sync. The SQL Server instances themselves operate completely independently from one another, unaware that they are part of a pool of database servers. xkoto claims that with Gridscale, applications typically require little to no modification beyond the use of a special database driver (standard ODBC or JDBC are two options) which talks to the database virtualization server (the gateway servers).
The Gridscale architecture also allows for on-the-fly addition of SQL server nodes to the cluster, as well as the ability to script a node to remove itself from the cluster while backups are performed and then the node can be re-added to the cluster and updated. If my notes are correct this has been tested out to twenty (20) nodes in a single cluster configuration. One slight limitation is that each gateway pair can only address a single instance of the SQL database engine per server (or in this day and time of virtualization, per operating system instance). So if you have multiple SQL instances per server (not multiple databases now, multiple instances of the SQL database application engine in memory), then you'll need to deploy multiple Gridscale gateway pairs.
The xkoto Gridscale for MS SQL was just introduced back in September as a follow on to their very successful and mature Gridscale for DB2 product.
