PolyServe Database Utility for SQL Server

I recently tested HP's PolyServe Database Utility for SQL Server, which takes a unique approach to SQL Server consolidation and availability. HP acquired PolyServe in February 2007, integrating it into the HP StorageWorks Division. The new HP version includes major enhancements such as support for recovery of a PolyServe cluster at a remote site. Although it extends HP SAN management options, PolyServe also works with other brands of servers and SAN hardware. PolyServe supports several OSs, including Windows Server 2003 R2 64-bit and Windows 2003 or later 32-bit and Linux, as well as server applications such as SQL Server and Oracle. My review focuses on version 3.6 enhancements for SQL Server on Windows Server.

PolyServe is a software solution for managing both SQL Server consolidation and high availability. Using PolyServe, you can easily move SQL Server instances from server to server within a "matrix" of as many as 16 servers that are all connected to a common SAN. By stacking multiple SQL Server instances on a single database server, PolyServe helps consolidate multiple SQL Server instances into a smaller set of servers. For high availability, you can designate primary, secondary, and tertiary automatic failover locations for each SQL Server instance in the event of a server or instance failure. You can manage the matrix of servers using a grid-like view of SQL Server instances, their physical server locations, and designated failover locations, as Web Figure 1 shows. In addition, you can use the PolyServe installer to apply SQL Server service packs and security patches to entire groups of SQL Server instances.

PolyServe's approach to SQL Server consolidation and availability is unique because, unlike traditional virtualization software, PolyServe doesn't create a virtual machine (VM) with its own OS and file storage. Instead, PolyServe extends the native Windows Server host OS by virtualizing SQL Server instance names on the host Windows OS and by making storage volumes on a SAN accessible to multiple servers in the matrix. The virtualized SQL Server instances are just aliases for physical instances on the host Windows OS, so they don't require their own virtualized OS, as is the case with a VM. In addition, the PolyServe clustered file system extends the host Windows file system by making individual SAN LUNs available for mounting to multiple physical servers within the matrix. Normally Windows requires any SAN LUN to be owned by only one physical server at a time, but PolyServe removes that restriction.

To implement PolyServer, you begin by selecting as many as 16 SAN-connected servers that will belong to the PolyServe cluster (aka matrix). (The servers are running Windows Server, but aren't clustered using Windows Clustering.) Installing PolyServe puts a replaceable file system driver called PolyServe File System (PSFS) and the PolyServe service on each server. HP PolyServe provides an engineer to assist with designing and installing it into your environment.

To create a clustered file system on the SAN, PolyServe uses its NTFS-compatible PSFS driver to format the SAN LUNs into volumes that can be shared by one or more servers in the matrix. PSFS maintains Windows-compatible locking and concurrency on the files by using PolyServe's Distributed Lock Manager. The result is that you can mount a particular SAN LUN as drive G (e.g., for backups) on several or even all database servers in the matrix, something you can't do using standard Windows Server file drivers.

After installing a physical SQL Server instance, you use the PolyServe management utility to assign a virtual IP address and virtual SQL Server instance name to the physical instance. Using PolyServe's Dynamic Re-Hosting features, you can then install failover target instances for each virtualized SQL Server instance.

As you can see in Web Figure 1, you can view each virtualized SQL Server instance in the rows under Name. The physical database server names are shown vertically in the columns to the right. The cells show the status, current physical server location, and potential failover server locations for each virtualized instance. For example, the SQL_Finance instance currently resides on the server named blade5-w, indicated by the check mark, and that server is its primary location (indicated by the letter "p"). Its first failover location is to server blade1-w, although an instance can have more than one potential failover location.

PolyServe's failover for SQL Server instances differs from Windows failover clustering: The database servers need not be all from the same hardware vendor, and they can have different CPU and memory configurations. Because the underlying SAN volumes are already shared, there is no need for un-mounting and remounting disk resources during a failover—which Windows failover clustering requires.

PolyServe 3.6 enhances security by integrating with Active Directory (AD) to provide single sign-on (SSO) via Windows authentication. For managing the PolyServe matrix, this latest version of PolyServe adds role-based management that provides finer-grained security for Windows domain users and groups. For auditing, changes to the matrix configuration can be redirected to the Windows event log.

PolyServe simplifies management with a multi-node, multi-instance installer for SQL Server hotfixes and service packs. You can apply a patch to an instance in maintenance mode, and the installer automatically applies the patch to all the related dormant instances on the other servers in the matrix.

In addition, PolyServe helps you avoid name conflicts among default and named virtual instances. For example, if you name a virtual instance blade5-wINST2, it can retain the entire virtual instance name on any server it fails over to. This latest version of PolyServe also enhances the PolyServe Migration Toolkit to capture and manage DTS package migration from SQL Server 2000 to SQL Server 2005 and adds support for Microsoft Volume Shadow Copy Service (VSS) writer, a component of VSS. (PolyServe already supports SQL Server 2005 database snapshots.)

For disaster recovery, PolyServe supports the use of SAN-based block-level mirroring to a remote site. During recovery, PolyServe on the remote site will dynamically recover and rebuild the correct LUN mappings and remount the correct volumes to each server.

In my own experience, HP PolyServe Database Utility for SQL Server is most useful for managing SQL Server consolidated instances across several database servers, with the added benefit of failover clustering for those mission-critical instances requiring high availability. Management of the instances is very intuitive, making both the current locations of all instances, as well as their potential failover targets, visible at a glance. In addition, you can easily move instances from one server to another to further fine-tune your overall server load.