V
`
`E
`
`R
`
`I
`
`T
`
`A
`
`S
`
`
`
`W
`
`H
`
`I
`
`T
`
`E
`
`
`
`P
`
`A
`
`P
`
`E
`
`R
`
`VERITAS ClusterX™
`for MSCS
`
`The Management of Microsoft Cluster Server
`Computing Environments
`
`by Richard R. Lee
`
`President, Data Storage Technologies, Inc., and author of the book
`“Windows NT Microsoft Cluster Server”
`
`Oracle Exhibit 1009, Page 1
`
`

`

`Table of Contents
`
`Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
`
`Microsoft Cluster Server (MSCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
`
`Cluster-Aware Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
`
`The MSCS Cluster Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
`
`Management Challenges and Shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
`
`ClusterX for Microsoft Cluster Server (MSCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
`
`MSCS and VERITAS ClusterX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
`
`VERITAS ClusterX Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
`
`Summary and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
`
`Oracle Exhibit 1009, Page 2
`
`

`

`Overview
`
`Microsoft Cluster Server (MSCS) has quickly become the de facto solution for high-availability clustering in the Windows 2000
`and Windows NT space of the enterprise computing market. Although certainly not the first to market in the growing
`segment of high-availability computing (Digital, Tandem, NCR, VERITAS, Vinca and several other solutions were all available
`well in advance of MSCS), Microsoft has nonetheless captured the hearts and minds of most IT users based upon MSCS’s
`tight integration with the Windows operating system (OS), along with the use of a formidable team of hardware partners to
`co-develop and extensively test the product before release. These “Early Adopter partners” included IBM, Compaq, Tandem,
`Digital, NCR and Data General1—all leaders in clustering technology for the past 20 years and major contributors of
`intellectual property to MSCS.
`
`Like many clustering solutions of the day, Microsoft Cluster Server (Version 1.0 was part of Windows NT Enterprise Edition,
`which was released in the fall of 1997) can be both difficult to deploy and challenging to manage. It uses a centralized
`management console—the Cluster Administrator (CA)—for setup, manipulation and monitoring of all Resources and Failover
`Groups, which can be most challenging when used with individual two-node clusters and virtually impossible in multicluster
`environments2.
`
`To create a more manageable MSCS environment, one that delivers on the clustering promises of TCO reductions and
`availability enhancements, VERITAS Software has developed an MSCS cluster management solution: VERITAS ClusterX™ for
`MSCS. It is a cluster, application and NT service configuration/management solution for use by administrators in MSCS-based
`computing environments. Announced in 1998 by NuView, Inc., and acquired by VERITAS in August 1999, ClusterX is now
`available in its third version (3.0) with many enhanced features and benefits for MSCS administrators to use in any size
`Microsoft Cluster Server–based computing environment. ClusterX has been especially tailored to manage distributed clusters
`in anyone’s enterprise computing environment.3
`
`Within the context of this white paper we discuss the background of both MSCS and ClusterX. You will quickly see why
`ClusterX is becoming the de facto Cluster Management Solution for MSCS, regardless of the size of the deployment (from a
`single-cluster HA solution to an enterprise-oriented, multicluster environment).
`
`1 Intel was also an “early adopter” partner acting in a consultative capacity based on its CPU and system chipset technology expertise, as well as in respect to its
`Standard High-Volume Server motherboard market initiatives.
`2 Using the CA, you can open connections to multiple clusters (by name), but can manage only one cluster environment at a time. Most multicluster environments
`use a dedicated NT Workstation running CA for each cluster (these workstations must have unique IP addresses established at the time the cluster is first set up).
`3 A recent survey of 150+ MSCS administrators conducted by Giga Information Group and Sunbelt Software indicates that many sites already have multiple
`MSCS clusters deployed, with more planned for the future.
`
`w w w . v e r i t a s . c o m
`
`T h e M a n a g e m e n t o f M i c r o s o f t C l u s t e r S e r v e r C o m p u t i n g E n v i r o n m e n t s
`
`P a g e 1
`
`Oracle Exhibit 1009, Page 3
`
`

`

`Microsoft Cluster Server
`
`Microsoft Cluster Server today is a two-node (in WIndows 2000 Advanced Server) or four-node (in Windows 2000 Datacenter
`Server) high-availability solution for use in application environments that require major enhancements to Availability4 with
`respect to stand-alone NT Server solutions5. It is based on the use of intelligent middleware that resides between the Windows
`operating system and the applications and services that the user would like enhanced.
`
`MSCS uses a “shared nothing” architectural model, in which each node (server) has ownership of specific storage resources
`located on a shared-storage bus (SCSI, FC or SSA) except in times of failover. During failover, these storage resources are
`transferred in ownership (via SCSI lock/release commands) from the failed node to the surviving node. The surviving node has
`duplicate instances of those applications that we designated for failover installed on it, which are then started once the Cluster
`Executive initiates transfer of storage resource ownership, along with all the other resources (if any) in the Failover Group6.
`The surviving node after this transfer and subsequent start-up of its copies of the failed application or service then resumes
`operations that were interrupted at the time of the failover, e.g., file and print sharing, Web services, database transactions and
`queries (via roll-back restart to the last “committed” transaction). The surviving node also takes ownership of the Quorum
`Resource, a special disk or volume that contains the cluster database7. This mode of operation continues until such time as
`the failed node is revived and brought back online8. At that time, the failed node (or application/NT service) can then have its
`physical disk resource (and others in the Failover Group) transferred back to its ownership on either an automatic or a manual
`basis. It then resumes normal operations until such time as a failure on either node (or its applications/NT services) occurs again.
`
`Client
` Network
`
`SCSI, SSA or
`Fibre Channel
`Storage
`Interconnect
`
`Cluster
`Interconnect
`Network
`
`VIA
`Hub/Switch
`
`Node
`1
`
`Node
`2
`
`Boot
`
`Boot
`
`Quorum
`Resource
`
`Node-1
`Disk
`
`Node-2
`Disk
`
`Figure1: An architectural block diagram of MSCS deployed in an Active/Active mode
`
`4 MSCS provides improvements in Scalability through the use of Symmetric Virtual Servers. SQL Server 7.0 can operate in this mode. Manageability enhancements
`have been limited to a Single System Image for the most part until the recent availability of VERITAS ClusterX.
`5 Windows NT Server Standard Edition provides approximately 97% availability out of the box. Using Windows NT Enterprise Edition, including MSCS, along
`with other built-in availability enhancement techniques can improve availability to approximately 99.5%.
`6 The Physical Disk Resource is the most basic individual resource used by MSCS and its Failover Groups. All Failover Groups are composed of at least a Physical
`Disk Resource.
`7 Only one node can own the Cluster Resource (either a disk or a logical volume). Its ownership is determined by a special Quorum algorithm.
`
`P a g e 2
`
`V E R I TA S C l u s t e r X f o r M i c r o s o f t C l u s t e r S e r v e r
`
`w w w . v e r i t a s . c o m
`
`Oracle Exhibit 1009, Page 4
`
`

`

`MSCS can be deployed on an application-by-application basis in a number of ways. Five deployment models are outlined by
`Microsoft. Each takes advantage of the specific attributes that MSCS has to offer in respect to enhancing availability,
`scalability and manageability. These five basic models are as follows:
`
`1. Active/Active: In Active/Active mode, both nodes are allowed to have varying workloads and applications residing on
`them. They each perform work independent of the other, with instances of those applications set up for
`failover/failback residing on both nodes.
`
`2. Active/Standby: In Active/Standby mode, the active node is online and doing work, while the inactive node sits in a
`“hot standby” mode waiting for any type of failure to occur on the primary node.
`
`3. Partial Cluster Solution: In this mode, a mixture of applications/resources can Failover/Failback, along with those that
`cannot (non-cluster-aware). The cluster-aware applications are set up in a normal manner under MSCS using shared
`storage resources, and those that aren’t use local storage resources found on the node where they permanently reside.
`
`4. Virtual Server Only: This model uses MSCS virtual server mode, without having formed an actual cluster. It can be
`deployed on any node that has cluster server running at the time.
`
`5. Hybrid Solution: The hybrid model is a combination of all the others previously described.
`
`These deployment models are intended to support several types of Failover scenarios. These scenarios are designed to be
`tailored to the specifics of each application type. Typical of these scenarios are the following;
`
`A. Automatic Failover with Automatic Failback: In this scenario, the application or service that fails or becomes
`unavailable automatically fails over to its alternate node when there is a loss of heartbeat or, in the case of a cluster-aware
`application, when the “LooksAlive” and “IsAlive” messages are not returned. When the failed node or application returns
`to its normal state and the heartbeat has been re-established, then the Failover Group’s resources are all returned
`automatically to their original state and owner.
`
`B. Automatic Failover/Manual Failback: In this scenario, the failed node or application is brought back online manually
`by the administrator. This allows for thorough testing and monitoring before the transfer—eliminating any potential for
`the Failover Group to fail again and potentially bringing down the entire cluster.
`
`C. Manual Failover/Manual Failback: This scenario is used for facilitating rolling upgrades and routine maintenance of
`the cluster. Using full manual control of the cluster, the administrator can bring applications, services and the node itself
`offline gracefully, with full monitoring. All designated applications can then be restarted on the alternate node, while
`upgrades or routine maintenance operations are performed on the failed node. Once these are complete, this node can
`then be brought back online, and its original workload and Failover groups can then be transferred back. At that time,
`the alternate node can then be brought offline, and its workload can be transferred to the alternate node, so that it
`can undergo routine maintenance or have applications upgraded.
`
`These are just a few of the Failover scenarios that are supported by MSCS. The administrator has the option of creating many
`more depending upon his or her requirements on an application-by-application basis.
`
`8 MSCS, like many other clustering solutions, uses a “heartbeat” signal to monitor the status of nodes in the cluster. This heartbeat signal is sent over a “private
`network” used for internode communications only. The heartbeat in its most rudimentary form is a single “ping” that is sent back and forth between the nodes
`at specific intervals. If this ping signal is not returned for any reason, the Cluster Executive attempts to use the Public Network or the SCSI bus to re-establish a
`heartbeat. In the event that all of these paths fail to respond to the heartbeat ping, then the cluster will begin Failover.
`
`One of the key differentiators found in MSCS with respect to other NT-based clustering solutions is the use of a “cluster-aware” API developed by Microsoft and
`its partners. This API is used to create cluster-aware applications and services that increase the granularity of Failover detection down to specific applications
`and services, rather than just nodewide, allowing failed applications and services to be failed over as opposed to the entire node. Most system failures or
`“hangs” are software driven according to statistics found today, so this increase in granularity allows for software errors to be overcome without failing over
`an entire node and all its applications and services.
`
`w w w . v e r i t a s . c o m
`
`T h e M a n a g e m e n t o f M i c r o s o f t C l u s t e r S e r v e r C o m p u t i n g E n v i r o n m e n t s
`
`P a g e 3
`
`Oracle Exhibit 1009, Page 5
`
`

`

`Cluster-Aware Applications
`
`One of MSCS’s most significant differentiators with respect to competing clustering solutions is its software interface specification,
`the “Wolfpack API.” This API (some 120+ pages in length) is designed to let software developers take full (or partial) advantage
`of the power of MSCS with the applications that they develop. It significantly increases the granularity of failure detection
`(down to the service level) and provides mechanisms for more comprehensive application monitoring and reporting. In future
`versions of MSCS, it will be used to help provide unprecedented levels of linear scaling through internode communications
`(use of the MSCS private network and the VIA specification).
`
`Wolfpack API
`
`Management Function
`
`Function Call
`
`Description
`
`Cluster
`
`Cluster
`
`Node
`
`Resource
`
`Group
`
`OpenCluster
`
`SetClusterName
`
`EvictClusterNode
`
`Open a connection to a cluster.
`
`Set the name for a cluster.
`
`Delete a node from the cluster db.
`
`FailClusterResource
`
`Initiate a resource failure.
`
`MoveClusterGroup
`
`Move a group and its resources to another node.
`
`Configuration
`
`ClusterRegOpenKey
`
`Open a config db key.
`
`Figure 2: A sampling of commands from the Wolfpack AP
`
`Early usage of this API has been dominated by Microsoft in the form of Enterprise Editions of its familiar BackOffice products.
`These include:
`
`• SQL Server 7.0 (and 6.5) and SQL Server 2000
`
`• Exchange 5.5 and Exchange 2000
`
`• Internet Information Service
`
`• Message Queue Server
`
`• Transaction Server
`
`• SMB File Share
`
`• Print Spooler
`
`All take advantage of the Wolfpack API in one manner or another (LooksAlive vs. IsAlive) and can be easily configured as
`virtual servers (including symmetric).
`
`These cluster-aware applications provide significant availability enhancements over their non-cluster-aware counterparts (with
`some scalability enhancements as well when you use virtual symmetric servers and partitioned data sets), but can be difficult
`to set up and administer. These applications come bundled with setup wizards, but much of the work in setting them up is
`done via the Cluster Administrator on a manual basis. This can prove tedious and confusing to the untrained administrator
`and can be a source of errors for even the well-trained administrator.
`
`P a g e 4
`
`V E R I TA S C l u s t e r X f o r M i c r o s o f t C l u s t e r S e r v e r
`
`w w w . v e r i t a s . c o m
`
`Oracle Exhibit 1009, Page 6
`
`

`

`The MSCS Cluster Administrator
`
`Included with MSCS is a management and configuration tool: the Cluster Administrator or CA. It is an explorer-type GUI for
`use in setting up, managing and monitoring your cluster. The Cluster Administrator must be run on a Windows 2000 or NT
`workstation designated during setup and provides the interface to the cluster during every phase of its operation9. The Cluster
`Administrator also contains a number of setup wizards for creating and installing applications and services on the cluster.
`
`Figure 3: CA View of a Cluster-aware application and its Resources (Exchange 5.5 EE)
`
`Although straightforward in approach, the CA can be very challenging and difficult to use in day-to-day administration of
`MSCS. Many of these challenges are driven by the lack of true visualization of the cluster and its resources during operation
`and setup. The administrator is left in many cases to fend for himself or herself to determine the status of key services and
`hardware components not displayed by the CA.
`
`Figure 4: The MSCS Cluster Administrator. Shown on the right are the Resources in the Cluster Group
`
`All of the commands and functions in the CA are duplicated under a command line version known as Cluster.exe. These
`commands can be set up under several scripting scenarios including Windows NT Scripting Host.
`
`9 The Cluster Administrator can also be incorporated into the Microsoft Management Console as a snap-in.
`
`w w w . v e r i t a s . c o m
`
`T h e M a n a g e m e n t o f M i c r o s o f t C l u s t e r S e r v e r C o m p u t i n g E n v i r o n m e n t s
`
`P a g e 5
`
`Oracle Exhibit 1009, Page 7
`
`

`

`Management Challenges and Shortcomings
`
`The MSCS Cluster Administrator is sorely lacking in both functionality and flexibility. It is difficult to install and configure
`applications and Failover groups for even the most seasoned administrator. It has limited management functions and cannot
`span multiple clusters, much less perform rudimentary cluster tasks such as Load Balancing and Cluster Database protection
`and management. The need for a robust management tool that would overcome the limitations of the CA and maximize the
`capabilities of MSCS prompted the deveolpement of ClusterX.
`
`ClusterX for Microsoft Cluster Server
`
`ClusterX is generally described as a “one to many” management tool for use in MSCS-based clustering environments. It was
`designed to enhance the existing MSCS Cluster Administrator, in order to provide dramatic improvements in the scope of
`functionality options available to administrators, as well as to increase substantially the number of clusters that can be
`effectively managed from a single console. It was designed specifically for the Windows NT Server environment and is based
`on such Microsoft standards as:
`
`• COM (common object model) and DCOM (distributed COM)
`
`• ActiveX scripting technology (Jscript and Vbscript)
`
`• The Microsoft Management Console (MMC “snap-in”)
`
`• ActiveX Containers (ClusterX can be used with IE 5.0 or later)
`
`ClusterX was designed to be nonblocking to allow for multiple tasks to be performed on a parallel basis. It is also multithreaded
`in design to allow multiple commands to be processed simultaneously, with prioritization support of these same commands.
`
`ClusterX adds major functionality to any MSCS environment. The new capabilities that it provides are key to administrators’
`achieving the full capabilities of their MSCS clusters. These new capabilities are:
`
`• The creation of a load-balancing infrastructure across all cluster nodes.
`Administrators can now monitor workloads on each node on a real-time basis. Information is then displayed in terms of
`percentage use of available resources (CPU, etc.), allowing administrator to move Failover Groups off overworked servers
`to lesser used ones, while continuing to monitor them no matter where they ultimately reside.
`
`• The addition of backup and restore functions to protect Cluster Configuration Data.
`ClusterX allows the system administrator to back up the entire cluster configuration information. This data can then be
`used to restore the cluster in the event of a catastrophic failure (clusterwide or on a single node).
`
`• The support for duplicating Failover Groups across multiple clusters.
`A knowledge-based rules system allows administrators to set up and manage complex resources and applications.
`
`• The ability to move resources from one Failover Group to another.
`Using the Dependency View, administrators can simply “drag ’n drop” resources from one group to another.
`
`• The creation and manipulation of Failover Group Dependency Trees.
`Failover Groups and their complex dependencies can be manipulated and viewed in their logical context.
`
`• The creation of comprehensive logs for all cluster activities, problems and changes.
`User actions, and all other cluster activity, are logged and displayed in a consolidated Audit Log View. Multiple levels of
`filtering can be applied to display log information in the most relevant manner.
`
`• Setup wizards for use with cluster-aware applications and services.
`Advisors and wizards are provided for the most popular cluster-aware applications and Windows services to allow for
`enhanced setup and configuration. These tools can configure MSCS as well as the application themselves.
`
`P a g e 6
`
`V E R I TA S C l u s t e r X f o r M i c r o s o f t C l u s t e r S e r v e r
`
`w w w . v e r i t a s . c o m
`
`Oracle Exhibit 1009, Page 8
`
`

`

`All these major functional areas (as well as some others not mentioned here) provide significant enhancements over what is
`available with the MSCS Cluster Administrator. In total, ClusterX and its expanded capabilities deliver on the promises that
`MSCS (and Microsoft) made during its development with respect to improvements in Availability, along with attendant
`reductions in Management burden and costs—both key components of everyone’s efforts to reduce TCO, while increasing
`operational efficiencies.
`
`Figure 5: A VERITAS ClusterX enterprisewide view of clusters, failover groups and resources
`
`Figure 6: A hardware schematic view of two clusters managed by VERITAS ClusterX
`
`w w w . v e r i t a s . c o m
`
`T h e M a n a g e m e n t o f M i c r o s o f t C l u s t e r S e r v e r C o m p u t i n g E n v i r o n m e n t s
`
`P a g e 7
`
`Oracle Exhibit 1009, Page 9
`
`

`

`MSCS and VERITAS ClusterX
`
`Microsoft Cluster Server is the cornerstone of Microsoft’s efforts to move Windows into the Enterprise Computing space of
`the market. It solves major problems associated with availability, scalability and manageability that have plagued Windows
`since its earliest days. Given this significance, Microsoft and its hardware/software partners have invested heavily in MSCS
`with respect to core product development and testing. What they missed along the way in this process was creating a
`simple-to-use but powerful management environment for these clusters. They also apparently envisioned that end users
`would deploy MSCS only as autonomous clusters with little need to manage multiples of these in most circumstances. Both
`of these shortsighted decisions left a gaping hole in Microsoft’s first-generation cluster offering: MSCS.
`
`In addition, the growth in the number of cluster-aware applications available for MSCS exposed other shortcomings in the CA.
`Although many of these applications came with setup wizards, they did not set the application up correctly on the cluster itself.
`They merely set up the application and its single or multiple instances. The systems administrator then had to intervene and
`either set up the applications’ Failover Groups and their resources (including dependencies) in advance of installing the application
`itself, or tweak it after the fact. Administrators were left to their own devices to fashion dependency trees and to determine
`how they were structured. This did little to make IT managers believe that MSCS was going to save time and reduce costs.
`
`Responding to this growing level of frustration expressed by early adopters of this technology, VERITAS began to develop ClusterX
`as the enterprisewide, comprehensive management and configuration tool that systems administrators were looking for.
`
`ClusterX came to market at just the right time to meet the growing demands of MSCS deployers and administrators.
`ClusterX Version 1.0 filled in the most gaping holes in the management and configuration of MSCS, and the functionality
`has continued to grow to where it is today with VERITAS ClusterX for MSCS v3.0. The capabilities of ClusterX have not gone
`unnoticed within the MSCS hardware camps in the computer industry. At this time, Data General, Unisys and Dell Computer
`are bundling versions of ClusterX with their MSCS solutions. It is anticipated that this list will grow eventually to include all
`providers of MSCS solutions as ClusterX becomes the de facto standard for MSCS management and configuration.
`
`Figure 7: Several VERITAS ClusterX Dependency Trees on an MSCS Cluster
`
`P a g e 8
`
`V E R I TA S C l u s t e r X f o r M i c r o s o f t C l u s t e r S e r v e r
`
`w w w . v e r i t a s . c o m
`
`Oracle Exhibit 1009, Page 10
`
`

`

`VERITAS ClusterX Deployment
`
`The deployment of ClusterX is very straightforward. During installation, ClusterX assigns agents to each cluster node (server)
`that it manages. These agents provide feedback and logging to the ClusterX client workstation that is used for command
`and control. This data is then used to support policy-based management of each cluster, along with load-balancing activities.
`
`ClusterX is then configured for each cluster. This process is based on ClusterX’s “learning” the specifics of the cluster and its
`Failover Groups and resources. It also examines each cluster’s hardware configuration with respect to public and private
`network connections, CPU and memory information, physical disk devices, etc. All this information is then displayed to the
`administrator graphically, as well as logged by ClusterX.
`
`As shown in several of the figures in this white paper, ClusterX displays on a single console all information about the clusters
`its manages, with varying messages displayed as icons or pop-ups.
`
`With regard to interoperability with other systems used across the enterprise, ClusterX is easily integrated into the frameworks
`of such enterprise management applications as Unicenter TNG, HP Open View and Tivoli TME.
`
`Currently, ClusterX has advisors and wizards to support the most popular applications and NT services being deployed in
`MSCS environments. These include:
`
`• SMB File Shares
`
`• Print Spoolers
`
`• Microsoft Exchange 5.5 EE
`
`• Microsoft SQL Server 6.5/7.0 EE
`
`• Microsoft Internet Information Server 3.0/4.0
`
`ClusterX has demonstrated itself as easy to install and become familiar with—all within a short time from start-up. It has
`easy-to-read messages and icons and gives systems administrators all the information and tools required to manage and
`support MSCS clusters—regardless of how widely they are disbursed or the complexity of the applications and NT services
`that they have clustered.
`
`w w w . v e r i t a s . c o m
`
`T h e M a n a g e m e n t o f M i c r o s o f t C l u s t e r S e r v e r C o m p u t i n g E n v i r o n m e n t s
`
`P a g e 9
`
`Oracle Exhibit 1009, Page 11
`
`

`

`Summary and Recommendations
`
`Microsoft Cluster Server and ClusterX go hand in hand. They work synergistically to create a Windows clustering offering
`that rivals long-established high-availability solutions found in the UNIX and proprietary OS spaces of the marketplace. They
`combine forces to meet the challenge of improving the availability, manageability and, to a lesser extent, scalability of major
`Windows applications such as SQL Server, Exchange and IIS. In addition to improving these major shortcomings in Windows,
`they reduce costs. These costs are not only in respect to TCO (total cost of ownership), but include business losses due to
`downtime. MSCS and ClusterX reduce downtime losses from hundreds of hours per year to hours per year in many cases.
`In addition, with the current wave of service-level agreement offerings available from many vendors in the market, ClusterX
`allows MSCS users to monitor compliance effectively with these agreements.
`
`As MSCS evolves under the Windows 2000 umbrella, so will ClusterX. The need for ClusterX will not be eliminated by the
`introduction of this major upgrade of Windows—it will be enhanced. With the delivery of a multinode clustering solution
`from Microsoft looming on the horizon, the requirements for a “best of breed” management and configuration tool will be
`paramount. Investments in ClusterX today will be protected long into the future, enhancing the ROI of this investment even
`further.
`
`I recommend the use of ClusterX in any MSCS environment, regardless of size or complexity. It will go a long way in
`guaranteeing you the ROI increases and TCO reductions that clustering on Windows promised several years ago, along with
`making your application environment as bulletproof and manageable as possible.
`
`For further information on ClusterX and VERITAS, see the VERITAS Web site at www.veritas.com or phone 1-800-327-2232
`(in North America) or 1-407-531-7501.
`
`Richard R. Lee
`
`Data Storage Technologies, Inc.
`Dstnj@bellatlantic.net
`(201) 251-6620
`
`References:
`
`1. Microsoft Cluster Server general information and white paper links – www.microsoft.com/ntserverenterprise
`
`2. “Windows NT – Microsoft Cluster Server,” Richard R. Lee, © 1999 – Osborne/McGraw-Hill, ISBN 007-8825008 – www.osborne.com
`
`3. VERITAS Web site for VERITAS ClusterX information and to download a 60-day free trial copy – www.veritas.com/us/products/clusterx
`
`4. Microsoft Cluster Server – API Specification (now included in the Windows Platform Development Kit) – www.microsoft.com/msdn/sdk
`
`5. “The Economics of Clustering,” Richard R. Lee, Intelligent Enterprise Magazine, January 1999 – www.intelligententerprise.com
`
`P a g e 10
`
`V E R I TA S C l u s t e r X f o r M i c r o s o f t C l u s t e r S e r v e r
`
`w w w . v e r i t a s . c o m
`
`Oracle Exhibit 1009, Page 12
`
`

`

`V
`
`E
`
`R
`
`I
`
`T
`
`A
`
`S
`
`
`
`W
`
`H
`
`I
`
`T
`
`E
`
`
`
`P
`
`A
`
`P
`
`E
`
`R
`
`VERITAS Software Corporation
`Corporate Headquarters
`1600 Plymouth Street
`Mountain View, CA 94043
`650-527-8000 or 800-327-2232
`
`For additional information about VERITAS
`Software, its products, or the location of an
`office near you, please call our corporate
`headquarters or visit our Web site at
`www.veritas.com
`
`Copyright © 2001 VERITAS Software Corporation. All Rights Reserved. VERITAS, VERITAS SOFTWARE, the VERITAS logo, Business Without Interruption, VERITAS The Data
`Availability Company, and VERITAS ClusterX are trademarks or registered trademarks of VERITAS Software Corporation in the U.S. and/or other countries. Other product
`names mentioned herein may be trademarks or registered trademarks of their respective companies. Specifications and product offerings subject to change without
`notice. Printed in USA. February 2001.
`
`VER02-CLXMSCS-0000 • 90-00861-399
`
`Oracle Exhibit 1009, Page 13
`
`