Enter the Matrix

PolyServe's Matrix Server flexes its muscle when it comes to running fast, efficient server clusters.

• By Chris Wolf
• March 01, 2005

When I first started looking at PolyServe's latest Microsoft clustering software, I was a bit skeptical. The interface reminded me of a rusted-out, 1970s-era muscle car. It was sleek around the edges, but obviously needed a little body work. However, once I looked under the hood, it was an entirely different story.

I expected the look and feel of PolyServe's Matrix Server to behave like the Microsoft interface that I know so well. Once I fully understood PolyServe's architecture and its pioneering approach to clustering, though, I was impressed.

Under the Hood
Matrix Server is designed and built to run on Fibre Channel Storage Area Networks (SANs). There are several distinct advantages to working within this type of architecture; most notably is traditional server clustering's reliance on a shared-nothing architecture. To understand shared-nothing, think about children sharing a toy when only one child can play with that toy at a time. Shared-nothing clustering works the same way. One or more servers share storage capacity, but in reality only one server can play with a shared physical disk at a time. The argument for this approach has long been that concurrent I/O operations from multiple sources could corrupt the shared hard disk, so it's best that the disk be mounted on just one physical server at a time.

The disadvantage to this approach is that it doesn't support two-node, SCSI-connected clusters. If you want to build a cluster with PolyServe, you'll need a SAN. Most larger organizations that are building clusters today purchase SANs anyway, so I don't see this as a serious limitation.

REDMOND RATING Documentation 10% ————— 9 Installation 20% ——————— 10 Feature Set 30% ——————— 7 Performance 20% —————— 10 Management 20% —————— 8 Overall Rating: 8.6 ————————————————— Key: 1: Virtually inoperable or nonexistent 5: Average, performs adequately 10: Exceptional

With PolyServe's cluster file system architecture, each node in the cluster mounts the shared storage on the SAN. This means that during a failover, you won't incur any delays when the new active node in the cluster mounts the physical disk resource. And even with concurrent file system mounts, integrity is maintained by Matrix Server's Distributed Lock Manager, which locks mounted file systems so that only a virtual host's active node in the cluster can access them.

The major advantage to this approach is that cluster failovers don't have to wait for disk mounts to be completed. This can result in a failover being accomplished in seconds as opposed to several minutes. In situations where uptime is critical, a few minutes saved can equate to many thousands of dollars, so this makes PolyServe Matrix Server (starting at $3,000 per CPU) well worth the investment.

PolyServe maintains the flexibility of its cluster file system by using its own proprietary system, known as the PolyServe File System (PSFS). PSFS is marketed as being fully compatible with NTFS, and for the most part, this is true. In fact, you can manage files on PSFS volumes using Windows Explorer. As with NTFS, you can still use PSFS to configure sharing and NTFS permissions, as well as junction points. Unfortunately, it doesn't currently support Encrypting File System (EFS), but that's planned for a future release.

Matrix Server supports up to 16 nodes configured in a failover cluster architecture. It can use any combination of Windows 2000 Server or Windows Server 2003 operating systems. The virtual server entities that have the ability to failover to other physical servers in the Matrix are called virtual hosts. Each virtual host has a static IP address and can include disk resources and other services. Because it's designed to run on a SAN, Matrix Server supports Multi-Path input/output (MPIO) on both Brocade- and McData-switched SANs, which lets it take full advantage of fault-tolerant SAN fabrics. Also, if it detects a problem in the data path, Matrix Server will re-route data through the SAN using an alternate path. Matrix Server will also continue to monitor the failed data path and use it again once it's back online.

Road Test
As mentioned earlier, I was a bit skeptical when I first kicked the tires on Matrix Server. Some representatives from PolyServe admitted to me that while its interface was fully functional, it certainly could be sleeker. But beauty is in the eye of the beholder, so I'll let you decide.

The Matrix Server management interface, which you can install and run on any Windows desktop, is shown in Figure 1. From the Server view, which is selected in the figure, you can see that my test cluster had two physical nodes (racksaver6 and racksaver9). The racksaver6 node hosted two virtual hosts—vsql1 and vsql2—both running SQL 2000.

Note the "Alerts" portion of the Window in Figure 1. It shows problems that occur while the interface is connected to the Matrix, but doesn't reveal any alerts that occurred prior to the interface being started. Also, there are no date and time stamps present for each alert. In spite of the limitations within the Alerts portion of the interface, Matrix Server does support a "Notifiers" feature, which lets you configure scripts to execute when certain events occur within the cluster.

Figure 1. The Matrix Server management interface provides complete system status information, including Alerts. (Click image to view larger version.)

Next, I began setting up virtual hosts, which was an absolute breeze. To set up a file server, I used the installed "Solution Pack for CIFS," which presented a simple window for configuring the virtual file server host's parameters.

To add the CIFS virtual host, I first had to provide a name and IP address for the virtual host, then select the member nodes of the cluster upon which the virtual host could run. After this, my next task was to add a shared folder to the virtual host. I finished that off with just a few mouse clicks.

Once I had my virtual hosts online and configured, I was free to sit back and enjoy the ride. A nice feature of Matrix Server that made the ride that much more comfortable was the system view available by clicking on the Applications tab, shown in Figure 2. From a single view, I could check the status of all virtual hosts running on the cluster, and on which server each virtual host is active. The green arrow symbol tells me that the vsql-2 and Redmond-fs1 virtual hosts are both active on the node racksaver9.

Figure 2. Matrix Server's Applications view gives you the status of individual applications running on the cluster.

While I tested virtual SQL servers and CIFS file servers on the Matrix Server cluster, Matrix also supports Web services and Oracle 9i RAC. Be warned: One application noticeably absent from the supported list is Microsoft Exchange, but the folks at PolyServe are working on that for a future release.

A Worthy Contender
While the user interface may still need a few improvements, I don't know many cluster administrators that have the time to sit around and stare at a management tool all day. If you're looking for sheer performance and high availability, this product is worth serious consideration. Matrix Server's support for redundancy within a SAN, its use of a distributed lock manager to provide for cluster failovers in a matter of seconds, its ability to launch custom scripts based on cluster events, and 16-node scalability makes this product a serious force in the Windows storage landscape.