Double-Take Software

Following up on my last column on what you could do with GeoCluster (now part of Double-Take Availability); I’d like to take some time to explain an interesting phenomenon that end-users see in GC all the time. While inside the cluster manger GUI, GC disks behave exactly the same as shared-cluster disks, when you create a GC between two or more servers, you can see the disk volumes “attached” to the passive nodes in Windows.  This is much different behavior than a traditional shared-disk cluster, where the volumes only appear on the active node for that disk resource.

The reason this happens is due to the fact that GC needs to replicate data from the owning node for that disk resource to all passive nodes that could potentially become owners if resources are moved or fail over.  In a shared-disk cluster, no replication is performed, so the disks only need to be attached to one node at a time; but GC needs the volumes mounted for that replication to occur.  The end result is that if you open up My Computer or Windows Explorer on a passive node, you will see the volumes mounted at all times.  However, you will not be able to do anything with those volumes except view the contents on the drive.  This is less than even read-only privileges, as you won’t be able to do things necessary to open and read files, like change the Last Access or Last Modified dates.

The technology that allows a volume to be mounted, but not accidentally altered, is part of the GC solution set itself.  During configuration, GC inserts a blocking file system filter driver.  This allows GC to control the flow of read and write I/O to disk.  The system can be manually invoked in regular Double-Take Availability or Backup connections as well, but it is turned on by default for GC connections.  Only the node that currently owns the disk resource can bypass the block to read and write to the disk, replicating changes a the byte-level to all other potential owning nodes.

When an arbitration occurs, and the resources move to another node, the block is removed on that node only so that the cluster can resume normal operations.  Once the failed node is brought back into the cluster, GC will block that node’s volumes, allowing it to be re-synchronized and brought back into quiescence with the cluster as a whole.

The practical upshot of all this is the answer to two of our most common GeoCluster questions.  1) No, you cannot use the passive-node data for any purpose, even though you are able to view it in Windows Explorer. 2) Even though you can see the volumes and directories in Windows Explorer, replication will safely occur and the cluster will not be able to accidentally attach to the wrong node’s copy of the data.

Editor’s Note: This was taken from questions submitted to the Double-Take User Group and the email address info@doubletake.com. If you’d like to see your questions answered here in Double-Take 101: just reach out through either the group or via email.

Microsoft Clustering Services (MSCS) and related technologies have provided a stable, highly automated availability solution for many years now. As the technology has progressed through NT4 into Server 2000, 2003 and now 2008; more and better feature-sets have made MSCS an attractive solution for High Availability in a local environment. When looking at clustering, there are some limitations that have persisted, even into the current incarnation of MSCS, Server 2008 Failover Clustering (FC). While they do not detract from the overall usefulness of the clustering, they do create logical restrictions to how a cluster could traditionally be deployed.

The most well-known of these considerations is that a shared-disk architecture can both limit the physical distance between nodes of a cluster, and also impose a single copy of the data, creating a potential single-point-of-failure scenario. With some applications, such as Exchange 2007, application-based technologies have been able to overcome this requirement by altering how the cluster functions. This works for those specific apps, but doesn’t assist with other applications that are cluster-aware, but do not permit for Distributed Failover Clustering (DFC) natively like Exchange does.

GeoCluster, which was first introduced by Double-Take Software in the days of NT4, seeks to address this concern. Now a feature of the Double-Take Availability product line, GeoCluster extends Microsoft Clustering technologies on Server 2003 and 2008 to distribute data to more than one disk resource. This provides a higher level of data-redundancy to match the server-redundancy that the underlying cluster architecture provides.

Built to be configured along-side MSCS or DFC, GeoCluster allows you to configure volumes on each node which show as unified disk resources in the cluster manager. This allows you to use the GeoCluster replicated disks with any cluster-aware application, regardless of vendor. From a day-to-day perspective, the cluster acts identically to what you would see if you had a shared-disk architecture, but the similarities stop there.

GeoCluster uses the Double-Take Replication Engine to allow the owning node for each disk resource to replicate changes to data to all other potential owning nodes throughout the cluster. This ensures that each node which may be called upon to run the application will have a copy of all data that the application needs to run properly. GeoCluster supports the same number of potential nodes as the version of Windows will permit; so as long as the cluster design is valid for your OS, it will work with GeoCluster as well. By leveraging the Double-Take Replication Engine, we can provide byte-level, write-order intact copies, safely replicating data from one node to another even for complex applications and solution sets.

If an application on a node – or the node itself – fails, GeoCluster allows the native cluster technology to arbitrate which node should take over the responsibilities, and automatically begins protecting the data from that new owner to all surviving nodes listed as potential owners. Once the original node is fixed or replaced, the GeoCluster system will make sure a copy of the data is synced to it, and ongoing replication keeps it ready to resume its role once either you manually move the resources back or – if you have configured automatic moves to preferred owners – once the cluster moves the resources back. Safety systems integrated into GeoCluster will prohibit the Cluster from accidentally assigning resources to a node that is not properly protected, allowing for resumption of duties only after the data is intact on the original, repaired, node.

GeoCluster provides an automated and integrated methodology for replication of data between nodes of an MSCS or DFC, while allowing that cluster to function as if it were leveraging a shared disk architecture. As an added benefit, provided all hardware is cleared as Cluster Capable, the hardware for the individual nodes and their disk resources do not have to match. This allows you greater flexibility, more resiliency and extended reliability for highly critical applications that can take advantage of Microsoft Cluster Technologies

As always, you don’t have to take our word for it.  You can find out more right from Microsoft, check out this blog to see what the Microsoft Virtualization Team is doing with partners like Double-Take Software!