Ps Series Best Practices Deploying Microsoft® Windows

Transcript

PS Series Best Practices Deploying Microsoft® Windows® Clustering with an iSCSI SAN Abstract This Technical Report describes how to use PS Series storage arrays with a Microsoft Windows Server 2003 cluster. With PS Series storage arrays, you can set up a scalable, fault-tolerant, and easy-to-manage iSCSI SAN that increases data and application availability. Copyright © 2004, 2005 EqualLogic, Inc. October 2005 EqualLogic is a registered trademark of EqualLogic, Inc. All trademarks and registered trademarks mentioned herein are the property of their respective owners. Possession, use, or copying of the documentation or the software described in this publication is authorized only under the license agreement specified herein. EqualLogic, Inc. will not be held liable for technical or editorial errors or omissions contained herein. The information in this document is subject to change. PS Series Firmware Version 2.2.3 or later. Deploying Microsoft Windows Clustering in an iSCSI SAN ii Table of Contents Revision Information .......................................................................................................................... v Introduction to Clustering................................................................................................................... 1 Using a PS Series SAN as Shared Storage ......................................................................................... 2 Audience and Background Information ............................................................................................. 3 Planning the Configuration................................................................................................................. 5 Network Design Considerations ............................................................................................ 5 Planning Network Redundancy ............................................................................................. 6 Booting Servers from the SAN ............................................................................................. 8 Basic Cluster Setup Steps ................................................................................................................... 8 Setting Up the PS Series SAN .......................................................................................................... 10 Creating the Group .............................................................................................................. 10 Configuring PS Series Volumes .......................................................................................... 11 Restricting Access to Volumes............................................................................................ 13 Accessing Shared Storage ................................................................................................................ 14 Connecting Nodes to Volumes ............................................................................................ 15 Aligning Disk Sectors ......................................................................................................... 18 Configuring a Basic Disk .................................................................................................... 19 Assigning a Drive Letter and Formatting a Partition .......................................................... 19 Setting Up a Microsoft Cluster ......................................................................................................... 19 Creating the Cluster ............................................................................................................. 19 Modifying the Cluster Network Configuration ................................................................... 25 Adding a Node to the Cluster .............................................................................................. 28 Modifying Cluster Configuration Options .......................................................................... 33 Installing Cluster Applications ............................................................................................ 33 Testing Cluster Failover ...................................................................................................... 33 Expanding SAN Storage Online ....................................................................................................... 35 Increasing the Size of a PS Series Volume ......................................................................... 35 Increasing PS Series Group Capacity .................................................................................. 36 Strategies for Backup and Recovery ................................................................................................ 36 Deploying Microsoft Windows Clustering in an iSCSI SAN iii Protecting Cluster Data ....................................................................................................... 36 Choosing a Backup Method ................................................................................................ 37 Restoring Data ..................................................................................................................... 38 SAN and Network Upgrades ............................................................................................................ 39 Cluster Maintenance ......................................................................................................................... 39 Replacing the Quorum Resource ......................................................................................... 39 Removing a Node from a Cluster ........................................................................................ 41 Using WSRM and Scripts to Manage Clusters ................................................................................ 42 Migrating an Existing Cluster to PS Series Storage ......................................................................... 43 More Information and Customer Support ........................................................................................ 44 Deploying Microsoft Windows Clustering in an iSCSI SAN iv Revision Information The following table describes the revision history of this Technical Report. Technical Report Revision Date Change 1.0 August 15, 2005 Initial draft 2.0 October 13, 2005 Second draft The following table lists the software and hardware revisions used for the preparation of this version of the Technical Report. Vendor Product / Model Software Revision Microsoft® Windows® ServerTM 2003 Enterprise Edition with Service Pack 1 KB891957 Microsoft iSCSI Software Initiator Version 2.0 EqualLogic® PS Series Firmware Version 2.2.3 Deploying Microsoft Windows Clustering in an iSCSI SAN v Introduction to Clustering Businesses demand continuity⎯without putting undue pressure on staff or budget. Because customers suffer when critical services go offline, you must plan for unpredictable events. Now, you can meet this demand for 24x7 operations with a cost-effective solution: Windows Server 2003 clustering combined with a highly available and scalable PS Series storage. Server clusters based on Microsoft Cluster Service (MSCS) provide availability for applications through failover. The following list summarizes server cluster features: • Can be used for databases, e-mail services, line of business (LOB) applications, and custom applications. • Included with Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition. • Provides high availability and server consolidation. • Requires the use of shared storage. In a server cluster configuration, if the hardware or software fails and causes a service failure, the cluster will automatically restart the failed service on a functional cluster node. This service failover capability ensures that no data is lost, and there is little disruption to users. When the problem is corrected, the cluster can re-balance the services across all functional nodes. The following figure illustrates a service failover on a typical cluster configuration in which all nodes are running different services. In Figure 1, Service 1 on Node A fails over to Node B. Figure 1: Service Failover in a Server cluster Note: Although most clustered services run on only one node at a time, a cluster can run many services simultaneously to optimize hardware utilization. Deploying Microsoft Windows Clustering in an iSCSI SAN 1 Using a PS Series SAN as Shared Storage Traditionally, many cluster solutions use a mixture of direct attached storage (DAS) for system disks and shared storage such as parallel SCSI buses for shared data. This results in different data protection and management procedures and requires that the cluster nodes be physically close to one another. However, using DAS has introduced challenges in terms of cable length limitations and the ability to share storage. Frequently, the result is a very fragile storage configuration, and many solutions require special cluster switches, in addition to special controllers and disk arrays. Storage area network (SAN) configurations improve the ability to connect multiple cluster nodes to storage. However, the complexity and cost of traditional Fibre Channel SAN configurations makes deployment and maintenance difficult. PS Series storage overcomes the challenges of DAS and traditional SANs by providing a familiar technology for connecting servers to storage – Ethernet. An iSCSI (Internet SCSI) SAN provides an affordable and easy-to-manage shared storage solution for your cluster nodes. The basis of the SAN is a PS Series storage array, a no-single-point-of-failure storage device that combines reliability and scalability with an easy-to-use management interface for a single system view of the storage connected to an IP network. By grouping together one or more PS Series storage arrays, cluster nodes can be connected to a pool of shared storage that provides: • High availability. PS Series storage array hardware delivers redundant, hot-swappable components—disks, control modules, fans, and power supplies—for a no-single-point-offailure configuration. Components fail over automatically without user intervention or disrupting data availability. • Improved data protection. All data is protected with RAID and spare disks. Full component redundancy and hot service capabilities mean that online operation is assured. • Scalability. With a PS Series storage array, increasing array capacity is as easy as installing additional drives or adding network connections. Expand overall PS Series group capacity— from hundreds of gigabytes to hundreds of terabytes of storage—by adding arrays to the group. The new arrays are configured automatically, and the storage pool is expanded. During this process, data remains available with no impact on hosts and applications. There is no need to open a server cabinet or reconfigure an operating system. The additional storage space is immediately available for use by any application on any server because, in a cluster, all the servers have access to all the shared storage. • Easy and inexpensive management. Centralized storage means you can manage more storage, more efficiently. A simple setup utility lets you quickly configure an array on the network and create a PS Series group. In minutes, you have a functioning iSCSI SAN. Automation of complex operations like RAID configuration, disk sparing, data provisioning, and load balancing means that even novices can effectively manage the SAN. • Advanced management features. The PS Series comes standard with a comprehensive set of features including automatic load balancing, virtual volume management, space-efficient snapshots for instant backup and restore, volume cloning for rapid server provisioning, multipath I/O support, cluster support, and Auto-Replication capabilities⎯delivering a comprehensive disaster recovery solution. Deploying Microsoft Windows Clustering in an iSCSI SAN 2 Each array (member) in a group contributes disk space to the pool, which can store the cluster quorum resource in addition to the data used by the cluster applications. As needed, you allocate portions of the pool to volumes, specifying a size, access controls, and other attributes. Seen by servers as a single device, each volume is automatically load balanced across multiple disks and group members, as needed. Figure 2 shows a typical cluster configuration with a PS Series group as the shared storage. Figure 2: PS Series Group as the Storage in a Microsoft Server Cluster Audience and Background Information This Technical Report is designed for administrators who want to deploy Microsoft Windows clustering using a PS Series SAN as the shared storage. Although you do not need extensive network or storage system experience, it would be useful to understand the topics in the following list. With each topic, a pointer to further information is provided. • Microsoft iSCSI Software Initiator Version 2.0. http://www.microsoft.com/downloads/details.aspx?familyid=12CB3C1A-15D6-4585-B385BEFD1319F825&displaylang=en Deploying Microsoft Windows Clustering in an iSCSI SAN 3 • iSCSI Cluster Support. The following link leads you to a Microsoft Windows Server 2003 FAQ answering commonly asked questions about iSCSI cluster support. http://www.microsoft.com/windowsserver2003/technologies/storage/iscsi/iscsicluster.mspx • Technical Overview of Clustering in Windows Server 2003. The following link leads to a white paper giving an overview of the differences in clustering technology between Microsoft Windows Server 2003 and Windows 2000 Server. Some of the areas covered in the article are installation, integration, and network load balancing. http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx • Creating and configuring a server cluster under Windows Server 2003. The following link leads to step-by-step instructions for creating and configuring a typical single quorum server cluster using a shared disk on servers running the Microsoft Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition operating systems. http://www.microsoft.com/downloads/details.aspx?FamilyID=96f76ed7-9634-4300-915989638f4b4ef7&DisplayLang=en • Recommended hotfixes for Windows Server 2003-based server clusters (all included in SP1). http://support.microsoft.com/default.aspx?scid=kb;en-us;895092 • Windows Server 2003 Clustering Services Technology Center. The following link leads to how-to articles and an array of resources to help you get the most out of the technology. http://support.microsoft.com/default.aspx?scid=fh;EN-US;winsvr2003clust • Basic verification and configuration analysis. The following link leads to the Cluster Diagnostics and Verification Tool (ClusDiag), a graphical tool that performs checks on a preproduction server cluster and creates log files to help identify configuration issues prior to deployment in a production environment. http://www.microsoft.com/downloads/details.aspx?familyid=b898f587-88c3-4602-84deb9bc63f02825&displaylang=en • Network connections. The PS Series group must be correctly connected to the network. For more information, see the Technical Report Network Connection and Performance Guidelines on the EqualLogic Customer Support website. http://support.equallogic.com/cgi-bin/pdesk.cgi?do=tech_report • Server Virtualization. Microsoft Virtual Server 2005 is a cost-effective virtual machine solution designed for Microsoft Windows Server 2003. http://www.microsoft.com/windowsserversystem/virtualserver/default.mspx Note: If you are utilizing Virtual Server 2005, you will need to apply Virtual Server R2. The release of R2 contains support for iSCSI clustering. Deploying Microsoft Windows Clustering in an iSCSI SAN 4 Planning the Configuration The following sections describe issues you should consider when planning a Microsoft cluster deployment with PS Series storage. As with any complex implementation, proper and deliberate planning will yield a smoother installation, providing you with greater stability and uptime over the life of your cluster. There are many choices to make in designing a cluster, and all deployments will be different. Network Design Considerations Implementing the correct networking infrastructure is essential to trouble-free operation of your server cluster. This section provides guidelines for designing networks for use with a cluster. Typically you will have a minimum of three networks in use: • One or more data networks for applications. These are referred to as public networks. A data network can be made redundant using NIC teaming or by using multiple interfaces on separate subnets. • Heartbeat network. This is referred to as a private network. NIC teaming cannot be used on the heartbeat network. • Storage area network (SAN). The SAN can be made redundant by use of Microsoft’s multipath I/O (MPIO). NIC teaming can be used in a SAN; however, multipath I/O provides more intelligent, SAN-integrated load balancing capabilities. Each network (public or heartbeat) connecting the nodes of a cluster must be configured as a unique IP subnet. The IP subnet numbers for the networks connecting the cluster nodes must be different. For example, if a cluster node has multiple adapters attached to the same cluster network (and NIC teaming is not in use), only one adapter will be used by the Cluster service; the others will be ignored. A node having two or more network adapters without NIC teaming connected to the same network will not provide fault tolerance or load balancing and is not recommended. It is recommended that each data network and SAN be configured in a redundant fashion to provide the benefit of a no-single-point-of-failure configuration. This configuration would include multiple network switches so that each network can operate (and fail) independently. The SAN (for example, a PS Series group) must be a network separate from each data network and heartbeat network. On the SAN, each cluster node must have network connectivity to the PS Series group IP address. You can configure the SAN on the same or separate switches as the public and heartbeat networks. If using the same switches, you must use separate VLANs and TCP/IP subnets for each network. On your SAN, you can use either the Microsoft iSCSI Software Initiator or iSCSI HBAs. When using iSCSI HBAs, ensure that you configure these cards to use Storport drivers. Deploying Microsoft Windows Clustering in an iSCSI SAN 5 For optimal performance and high availability, EqualLogic recommends following these SAN network guidelines: • Use a switched, Gigabit Ethernet network. Connect storage arrays and hosts to a switched network and ensure that all network connections between hosts and arrays are Gigabit Ethernet. An array can operate at 10 and 100 Mbits, but performance will be significantly degraded. • Utilize fast convergence/fast spanning tree. The Spanning Tree Protocol (STP) has a measurable convergence time. When a switch participating in spanning tree fails, the protocol needs to recalculate who is going to be the “root” switch. During this time, you will experience a network service interruption on that segment while this re-convergence happens. RSTP allows a switch port to bypass the Spanning Tree listening and learning states and quickly enter the STP forwarding state. Utilizing Rapid Spanning Tree Protocol (RSTP, 802.1w) can speed up the time it takes to recalculate spanning tree, thus reducing network service interruption. You will need to consult your switch manufacturer’s documentation to verify if your switches are RSTP-capable and how to configure for RSTP. • Use flow control. Enable Flow Control on each switch port that handles iSCSI traffic. If your server is using a software iSCSI initiator and NIC combination to handle iSCSI traffic, you must also enable Flow Control on the NICs to obtain any performance benefit. PS Series storage arrays will correctly respond to Flow Control. • Enable Jumbo Frames. If supported by all the devices in the network path between hosts and arrays, enable Jumbo Frames on each switch that handles iSCSI traffic. This support is usually disabled by default. If your server is using a software iSCSI initiator and NIC combination, you must also enable Jumbo Frames on the NICs that handle iSCSI traffic to obtain any performance benefit and ensure consistent behavior. • Configure multiple network interfaces on an array. Connect them to different switches. • For a multi-subnet PS Series group, provide access to the subnet on which the group IP address for all enabled network interfaces on the group members. • Use redundant paths between iSCSI initiators and storage arrays. Multipath I/O ensures that no single point of failure exists between initiators and arrays. This can be achieved by using Microsoft’s MPIO solution. Additional details on these guidelines can be found on the EqualLogic Customer Support website in the Technical Report Network Connection and Performance Guidelines. The EqualLogic Customer Support website requires a login account. Planning Network Redundancy Because you are deploying a cluster to make your applications fault tolerant, you should do the same with the network. As described earlier, you have to apply certain rules when configuring redundancy for the different network segments of your cluster. The public network can be made redundant using NIC teaming or by configuring multiple interfaces on separate subnets. The network that is enabled for internal communication between cluster nodes, typically a private network, must not be teamed. The SAN network should use multipath I/O for redundancy. Deploying Microsoft Windows Clustering in an iSCSI SAN 6 When used with a PS Series group, full cluster redundancy at the network level may require five network interface cards (NICs). You can accomplish network redundancy in the server by using the following: • Teaming or multiple interfaces on separate subnets. These are the only two supported options for the public network. Consult your network adapter manufacturer’s website for the details and drivers needed to team your specific environment. • Two NICs or iSCSI host bus adapters (HBAs) for SAN traffic, utilizing multipath I/O. • One NIC for the private internal cluster communications or heartbeat. As a best practice, ensure that the network adapters used in all cluster nodes are identical. Whether using the server’s on-board (built-in) network adapters or add-on PCI/X cards, they should be the same make, model, and firmware version on each network. The following table shows an example of planning IP addresses for a cluster. Table 1: Cluster Name and IP Assignments Node A Interface SAN IP Address 192.168.0.11 Subnet Mask 255.255.255.0 SAN 192.168.0.12 255.255.255.0 Public Private 172.16.100.212 10.10.10.1 255.255.255.0 255.255.255.0 172.16.12.1 N/A IP Address 192.168.0.13 Subnet Mask 255.255.255.0 Gateway SAN 192.168.0.14 255.255.255.0 Public Private 172.16.100.222 10.10.10.2 255.255.255.0 255.255.255.0 Node B Interface SAN Gateway Note Using MPIO. Gateway optional. Using MPIO. Gateway optional. Teamed/virtual values. Do not assign gateway. 172.16.12.1 N/A Note Using MPIO. Gateway optional Using MPIO. Gateway optional Teamed/virtual values. Do not assign gateway. IP Address 172.16.100.10 172.16.100.12 Note Cluster configuration. Application configuration. Cluster Short Name cluster0 clus-sql FQDN (DNS) cluster0.acme.com clus-sql.acme.com Deploying Microsoft Windows Clustering in an iSCSI SAN 7 Booting Servers from the SAN A PS Series group gives you the option of booting cluster nodes from SAN volumes (also called a SAN boot). SAN boot is a feature that places your system disk and pagefile on the SAN rather than on DAS storage. This removes the need to purchase, install, and configure additional controllers and disks commonly used to provide mirrored system disks. Using SAN boot improves server operations by placing the operating system on a highly available SAN with snapshot and replication capabilities. The result is improved data protection and server management, in addition to the ability to recover quickly in the event of server hardware failure. Using SAN boot requires a QLogic™ QLA4010 host bus adapter (HBA). See the Technical Report Booting Windows 2003 from a PS Series SAN on the EqualLogic Customer Support website for more information. Basic Cluster Setup Steps This section outlines the basic steps needed to use a PS Series SAN as the shared storage for a Microsoft Windows Server 2003 cluster. The steps assume that you have already completed the hardware installation and setup of your group as described in the PS Series QuickStart. A good source of information for general Windows setup information is the Technical Report Deploying Microsoft Windows Server 2003 in an iSCSI SAN, located on the EqualLogic Customer Support website. Because you are using a shared storage device, when you power on and start up the operating system, it is vitally important that only one node have access to a shared volume at one time. Otherwise the shared volumes can become corrupted. Once the cluster service is running properly on one node, the other nodes can be added and configured. 1. Set up a PS Series group and create the volumes required for the cluster environment. Create the following volumes: • Quorum resource volume. Microsoft requires that you configure the quorum disk with a size of 512 MB. • Volumes for service data, as needed. Be sure to create one or more access control records for each volume to allow only the cluster nodes access to the volume. In addition, reserve snapshot space for each volume if you want to create volume snapshots or use Auto-Snapshot Manager for VSS backups. For more information, see Setting Up the PS Series SAN. Optionally, you can also create volumes for booting cluster nodes from the SAN, a VSS control volume if using Auto-Snapshot Manager, or volumes for disk backup media. You can access the PS Series Group Manager from a server (through a web browser, telnet, or ssh connection to the group IP address) or a serial connection to a group member. 2. Optimize the SAN network for performance. See the EqualLogic Technical Report Network Connection and Performance Guidelines for more information. Deploying Microsoft Windows Clustering in an iSCSI SAN 8 3. Optionally, configure the environment so that the cluster nodes can boot from the SAN. For details, see the EqualLogic Technical Report QLogic QLA4010: Booting Windows 2003 From a PS Series Group SAN 4. Install the operating system on each node. Requirements include Microsoft Windows Server 2003 Enterprise or Data Center Edition, Windows Server 2003 Service Pack 1, any needed hot fixes, and all non-cluster software. The cluster service is part of Windows Server 2003 and does not have to be installed separately. If utilizing SAN boot, install the operating system on a PS Series volume that is not shared among the cluster members. To boot a Windows server from the SAN, you need a QLogic QLA4010 iSCSI host bus adapter. See the Technical Report Booting Windows 2003 from a PS Series SAN on the EqualLogic Customer Support website for more information. 5. Install an iSCSI initiator on each node and any NICs or HBAs. This Technical Report uses the Microsoft iSCSI Software Initiator. As an alternative, you can use an iSCSI HBA plus the Microsoft iSCSI Software Initiator service, which is delivered as part of the initiator. Note that you need multiple NICs or HBAs for multipath I/O. For the information about using the initiator to access PS Series storage, see the Knowledge Base on the EqualLogic Customer Support website. For installation information, see the initiator vendor documentation. 6. On the first node, use the iSCSI initiator to connect to the shared volumes and format the volumes. Start the iSCSI initiator and log in to the iSCSI targets associated with the volumes you set up in Step 1. Use the group IP address as the target portal or discovery address. Be sure to establish a persistent connection to the volume and bind the volume so it is available when needed. Once connected, the volumes appear as disks in the Disk Management utility. Then, align the disks sectors, configure each iSCSI disk as a basic disk, and assign a drive letter. See Accessing Shared Storage for more information. 7. Allocate static IP addresses on your public network. You need an IP address for the cluster and for each cluster application you will be running. These will be the “virtual” IP addresses that will be utilized to access each cluster-configured resource. The IP layout was described in the section Planning Network Redundancy. You will probably have a minimum of two IP addresses: one for the cluster itself and one for the application you will install. 8. Create a corresponding DNS name for each IP address you allocated in Step 7. The cluster application you will be running will be referenced by a name that should be entered into your DNS system. This DNS name will be referenced in order to access cluster configured resources. 9. Create a unique Active Directory account for your cluster service to run under. Do not add this account to the Domain Administrators group. It is best if the cluster service user account is a new account. The account must have local administrative rights and permissions on the cluster nodes. Be sure to keep the password from expiring on the account. (Follow your organization’s policies for password renewal.) It is strongly recommended that you do not use the same account for the cluster service and the applications in the cluster (for example, Microsoft SQL Server). If you do use the same account, you may not be able to later change the cluster service password without disrupting your cluster applications. Deploying Microsoft Windows Clustering in an iSCSI SAN 9 10. Configure Microsoft Clustering Services on the first node. This is described in Creating the Cluster. Note: If you want to use SAN boot, you will also need to make registry changes on each cluster node to allow SAN boot in the cluster. These are detailed in the Microsoft article at the following location: http://support.microsoft.com/default.aspx?scid=kb;en-us;886569 11. On the first node, modify the cluster network configuration. This is described in Modifying the Cluster Network Configuration. 12. On the second node, use the iSCSI initiator to connect to the shared PS Series volumes. Start the iSCSI initiator and log in to the iSCSI targets associated with the volumes you set up in Step 1. Use the group IP address as the target portal or discovery address. Be sure to establish a persistent connection to the volume and bind the volume so it is available when needed. Once connected, the volumes appear as disks in the Disk Management utility. Note: Do not align disk sectors or format the disk on the second node. It is important to verify that the disks on the second node are labeled “not initialized” (instead of “online”). This indicates that the SCSI reservation (to the first node) has been honored by the storage subsystem. Therefore, one node will not be able to corrupt data by writing to a disk that has been reserved by another node. See Connecting Nodes to Volumes for more information. 13. Add a second node to the cluster. This is described in Adding a Node to the Cluster. 14. Consider modifying cluster configuration options. This is described in Modifying Cluster Configuration Options. 15. Install the applications that will run on the cluster nodes. See Installing Cluster Applications for more information. 16. Test the cluster. See Testing Cluster Failover for more information. Setting Up the PS Series SAN The following sections describe how to create a PS Series group, create volumes, and restrict access to the volumes. Creating the Group For detailed information about setting up PS Series storage array hardware and getting started with a group, see the PS Series QuickStart. The Group Administration manual describes detailed information about volume setup and advanced group management using the graphical user interface (GUI). See the CLI Reference manual for information about using the command line interface (CLI) to manage a group and individual arrays. The documentation is available on the EqualLogic Customer Support web site. Deploying Microsoft Windows Clustering in an iSCSI SAN 10 Use the Group Manager GUI or CLI to manage a group. Access the GUI from a web browser by connecting to the group IP address. Access the CLI from a telnet or ssh connection to the group IP address or a serial connection to a group member. Once connected to the group, log in to an administration account such as grpadmin. When creating a group and configuring arrays as group members, keep in mind the following: • Choose the group RAID level that is optimal for your application performance. Before creating a PS Series group, you should determine which RAID level, either RAID 10 or RAID 50, to configure on the group members (storage arrays). Note that both RAID levels provide adequate performance and fault tolerance for a wide range of data types, such as NTFS volumes, and applications, such as Exchange and SQL Server. For more information on RAID levels in a PS Series group, see the Technical Report Understanding Group RAID Levels on the EqualLogic Customer Support website. • You need to configure at least two network interfaces on each group member in order to configure multipath I/O. For example, connect one network cable to the eth0 interface and another network cable to the eth1 interface. Then, connect the cables to different switches. Then, use the Group Manager GUI or CLI to configure each interface. Once the group is configured, you can create volumes and then access the volumes from the cluster nodes. Configuring PS Series Volumes You can use the Group Manager GUI or CLI to create volumes. For example, to use the GUI, connect to the group IP address from a web browser and log in to an administration account, such as grpadmin. The Group Summary windows appears. Click and expand items in the far left panel of the GUI for detailed information about group components. Tasks such as creating volumes are shown in the Activities panel. Group Manager – Group Summary Deploying Microsoft Windows Clustering in an iSCSI SAN 11 Create the following shared volumes: • One volume that will be dedicated for use as the cluster quorum resource. Microsoft requires that you configure the quorum disk with a size of 512 MB. • One or more volumes for application data (that is, service data). The sizes of these volumes depend on the individual application requirements. • Optionally, volumes for booting cluster nodes from the SAN, a VSS control volume if using Auto-Snapshot Manager, or volumes for disk backup media. To ensure proper security and data integrity, for each shared volume, create one or more access control records to allow only the cluster nodes access to the volume. Also, reserve snapshot space if you want to create volume snapshots or use Auto-Snapshot Manager. To create a volume, click Create Volume in the Group Summary window. The Create Volume diag box appears, as shown in the figure below. Enter a unique volume name and the volume size. Optionally, reserve snapshot space for the volume. The Space Utilization table shows the current group capacity and the capacity with the new volume. Group Manager – Create Volume It is recommended that you select meaningful volume names such as cluster1-quorum for the quorum volume, cluster1-data1 for a service volume, and cluster1-test for a testing volume. This helps to eliminate confusion if you have multiple clusters attached to the same PS Series group. Click Next to display the dialog box that enables you to set up an access control record for the volume, as described in Restricting Access to Volumes. Note that you can create and modify access control records for a volume at any time. Deploying Microsoft Windows Clustering in an iSCSI SAN 12 After you specify the access control information, click Next, confirm the volume configuration, and then click Finish to create the volume. The volume should appear when you expand Volumes in the far left panel of the GUI. Select the volume name to display volume details. Once you create a volume, an iSCSI target name is automatically generated for the volume. Servers connect to the volume through the group IP address and the target name. Restricting Access to Volumes All nodes in a cluster must have access to the shared storage (for example, the quorum volume and service volumes). Servers not in the cluster should not have access to the volumes. The cluster software ensures that only one cluster node can access a given volume at a time. Access control records are used to restrict host access to volume data in a PS Series group. A group volume and its snapshots share a list of access control records (sometimes called the access control list). You can configure a record to apply to the volume, its snapshots, or both, as needed. When you create a volume with the GUI or CLI, you can create an access control record at that time. You can also create and modify access control records at any time. For example, in the GUI, expand Volumes in the far left panel and select the volume name. Click the Access tab in the window that appears, and then either click Add or select an existing record and click Modify. If you click Modify, the Modify Access Control Record dialog box appears. In each access control record, you can specify an IP address, iSCSI initiator name, or CHAP user name (or any combination). A cluster node must match all the requirements in one record in order to access the volume or snapshot. Group Manager – Modify Access Control Record The most secure way to control access to your volumes is to use a combination of IP address and CHAP, as shown in the figure above. For example, if a record includes both an IP address and a Deploying Microsoft Windows Clustering in an iSCSI SAN 13 CHAP user name, a server must present the IP address and supply the CHAP user name and its associated password (using the iSCSI initiator) in order to match the record. If only a CHAP user name is specified in a record, initiators that support discovery will unsuccessfully try to connect to the volume, increasing event log activity. You can also specify whether the record applies to the volume, the volume snapshots, or both. Notes: If you use IP addresses or iSCSI initiator names to restrict access, create an access control record for each IP address or initiator name presented by the server. For example, if a server has two NICs that are handling iSCSI traffic, create two records, one with the IP address assigned to one NIC and the other with the IP address assigned to the other NIC. This ensures that the server can access the volume (or snapshot), regardless of which NIC is used for the connection. To use CHAP to restrict host access to volumes, you must configure CHAP in the group, as described in the PS Series Group Administration manual. You can allow unrestricted access to a volume (only recommended for a test volume) by specifying 0.0.0.0 for an IP address and not other credentials Once you specify the access control information, click OK to create the record. The record should appear in the Group Manager Volume Access window, as shown below. Group Manager – Volume Access Accessing Shared Storage The following sections describe how to connect nodes to the PS Series volumes, align disk sectors for optimal performance, create a basic disk, and assign a drive letter. Although all cluster nodes must be connected to the shared volumes, you only have to align disk sections and format the disks on the first node in the cluster. Deploying Microsoft Windows Clustering in an iSCSI SAN 14 Connecting Nodes to Volumes After an iSCSI initiator is installed on a cluster node, you can connect the node to the shared volumes, including the quorum resource volume and the service volumes. A volume is seen on the network as an iSCSI target. When you create a PS Series volume, the group automatically generates an iSCSI target name. The volume name is appended to the end of the target name. Once the initiator logs into the volume, it appears as a local disk (called an iSCSI disk) in the Disk Management utility. Note: To access a volume, a node must supply an IP address, iSCSI initiator name, or CHAP user name that matches the information in one of the volume’s access control records. See Restricting Access to Volumes for more information. The following steps describe how to connect to a PS Series volume: 1. Launch the Microsoft iSCSI initiator. Click Start > Programs > Microsoft iSCSI Initiator > Microsoft iSCSI Initiator. The iSCSI initiator Properties dialog box appears. Microsoft iSCSI Initiator Properties – General Tab Deploying Microsoft Windows Clustering in an iSCSI SAN 15 2. Click the Discovery tab and then click Add. The Add Target Portal dialog box appears. Specify the PS Series group IP address (or its DNS name). Then, click OK. This will enable the initiator to “discover” the iSCSI targets associated with the group volumes. Microsoft iSCSI Initiator Properties – Add Target Portal 3. In the Microsoft iSCSI Initiator Properties dialog box, click the Targets tab. Microsoft iSCSI Initiator Properties – Targets Tab 4. Select the desired iSCSI target and click Log On. In the Log On to Target dialog box, check the box next to Automatically restore this connection when the system reboots. Deploying Microsoft Windows Clustering in an iSCSI SAN 16 5. If you want to use multipath I/O, in the Log On to Target dialog box, check the box Enable multi-path and then click Advanced. This enables you to specify multiple physical paths to the same target. See the EqualLogic Technical Report Deploying Microsoft Windows Server 2003 MPIO® in an iSCSI SAN for more information about configuring multipath I/O. Microsoft iSCSI Initiator Properties – Log On to Target Single Interface Log On Multipath I/O Log On 6. If the volume requires CHAP credentials, in the Log On to Target dialog box, click Advanced. The Advanced Settings dialog box appears. Check the box next to CHAP logon information and specify the required user name and secret (password). The information must match an access control record for the volume and an entry in a CHAP database set up in the group or on an external RADIUS server. After entering the information, click OK. Microsoft iSCSI Initiator Properties – Advanced Settings Deploying Microsoft Windows Clustering in an iSCSI SAN 17 7. In the Log On to Target dialog box, click OK to complete the login. 8. Confirm the connection by clicking the Targets tab in the Microsoft iSCSI Initiator Properties dialog box. The target should appear in the list with the status Connected. 9. In the Microsoft iSCSI Initiator Properties dialog box, click the Bound Volumes/Devices tab. To ensure that the volume will be available when the iSCSI service is started by Windows, click Bind All. Then, click OK. If you have an application that uses drive letters (for example, SQL or Exchange), perform the bind after assigning a drive letter. Microsoft iSCSI Initiator Properties – Bound Volumes/Devices Tab Once the node is connected to a volume’s iSCSI target, it appears as a local disk (iSCSI disk) in the Disk Management utility. Aligning Disk Sectors For optimal performance with PS Series volumes, it is recommended that you configure the volume disk partitions to begin on sector boundaries that are divisible by 64K (that is, evenly divisible by 65536 bytes or 128 sectors). This will make the sectors match the default PS Series storage array RAID stripe segment size and improve volume and overall group performance, especially with random I/O workloads generated by applications such as Microsoft Exchange or SQL Server. Deploying Microsoft Windows Clustering in an iSCSI SAN 18 Note: Aligning disk sectors should be done using the diskpar utility that is available from the Windows 2000 Resource Kit. Do not use the Windows Server 2003 utility diskpart to align disk sectors on a PS Series volume, because you will not achieve the desired results. For more information, see the Technical Report Microsoft Windows: Aligning Disk Sectors for Optimal Performance on the EqualLogic Customer Support website. Configuring a Basic Disk When you perform the disk sector alignment procedure, as described in the previous section, the default action will create a basic disk. Do not convert the disk to a dynamic disk, because there are limitations when using dynamic disks. Assigning a Drive Letter and Formatting a Partition After you have aligning disk sectors and created a basic disk, the new volume will be seen in the Disk Management utility as On-Line and Healthy. A disk associated with a connected PS Series volume is referred to as an iSCSI disk. Note: Although you can create multiple disk partitions on an iSCSI disk, it is recommended that you only use one partition. For details on assigning a drive letter and formatting an iSCSI disk, see the Technical Report Deploying Microsoft Windows Server 2003 in an iSCSI SAN on the EqualLogic Customer Support website. Setting Up a Microsoft Cluster The following sections describe how to implement a two-node cluster that uses PS Series storage. At this point, you should have the PS Series group and volumes setup; the Windows Server 2003 operating system installed, patched, and configured on the cluster nodes; and the nodes connected to the shared volumes. In addition, you should have implemented network redundancy for your “public-facing” nodes, as described in the section Planning Network Redundancy. Creating the Cluster Follow these steps to set up Microsoft clustering: 1. On the first node (Node A), click Start > Programs > Administrative Tools > Cluster Administrator. Alternatively, use cluadmin.exe from the command line or click Start > Run > cluadmin.exe. The Cluster Administrator appears. Deploying Microsoft Windows Clustering in an iSCSI SAN 19 Cluster Administrator 2. In the Cluster Administrator, select Create new cluster. This will start the New Server Cluster “wizard” that will guide you through the steps of setting up your cluster. Click Next to continue through the dialog boxes. Cluster Wizard Deploying Microsoft Windows Clustering in an iSCSI SAN 20 3. Select the domain in which you wish the cluster to participate. If you have more than one domain, you can select it from the Domain dropdown list. Specify a unique in the Cluster Name field. Click Next to continue. Cluster Wizard – Cluster Name and Domain 4. Specify the computer that will be the first node in the cluster. You can use the Browse button to select a server other than the one you are installing from. Click Next to continue. Cluster Wizard – Node Name Deploying Microsoft Windows Clustering in an iSCSI SAN 21 5. The Cluster Wizard will perform an analysis of the node you specified in order to verify the feasibility of the installation. If there are no errors reported, click Next to continue. Cluster Wizard – Analyzing Node Configuration 6. Specify the IP address that will be used to connect to your cluster. Click Next to continue. Cluster Wizard – IP Address Deploying Microsoft Windows Clustering in an iSCSI SAN 22 7. Specify the cluster service account user name and password you set up in Step 9 in Basic Cluster Setup Steps. Then, click Next. Cluster Wizard – Cluster Service Account 8. A dialog box with the proposed cluster configuration appears. Scroll down and verify your choices. Do not click Next at this time. Instead, click Quorum. Cluster Wizard – Proposed Cluster Configuration Deploying Microsoft Windows Clustering in an iSCSI SAN 23 9. In the Cluster Configuration Quorum dialog box, specify the iSCSI disk associated with the PS Series volume you configured for the quorum resource. Then, click OK. When the Proposed Cluster Configuration dialog box appears again, click Next to continue. Cluster Wizard – Cluster Configuration Quorum 10. The server will now create the cluster on the node you specified in Step 4. If the Cluster Wizard finds any errors, a condition will be flagged. You can expand the failed object to obtain the details needed to correct the problem. Click Next to continue if you do not have any critical errors that prevent the cluster from completing the configuration. Note: If you are using DHCP, you may receive a warning, as shown in the figure below, that one or more network adapters are configured to use DHCP. Although the cluster will perform with a network adapter set to use DHCP, it is not recommended. Cluster Wizard – Creating the Cluster Deploying Microsoft Windows Clustering in an iSCSI SAN 24 11. Once the cluster configuration completes, the Cluster Wizard will enable you to view the log. Click Finish to exit the wizard. Cluster Wizard – Complete Cluster Configuration Modifying the Cluster Network Configuration Once the cluster installation completes, the Cluster Administrator will show all the objects that were automatically created. You must make configuration changes that are specific to your cluster environment to the network object. Follow these steps to modify the cluster network configuration: 1. In the left panel, expand Cluster Configuration and click Networks. The network adapters active on the node will appear in the right panel. Cluster Administrator – Networks Deploying Microsoft Windows Clustering in an iSCSI SAN 25 2. One at a time, right-click each network object in the right panel and select Properties. Select the network option button that describes the function of the network adapter. If an adapter will not participate in the cluster, be sure to uncheck the box Enable this network for cluster use. Otherwise, if the adapter fails, the cluster will see it as a failure in the cluster and fail over services to another node. Click OK when finished. Cluster Administrator – Network Properties 3. Reorder the bind preference on the cluster node’s network adapters. Use the following order: a. External public network b. Internal private network (Heartbeat) c. SAN network On the node, click Start > Control Panel > Network Connections. From the menu bar, select Advanced > Advanced Settings. Use the arrow keys on the right to reorder the adapter list, as shown in the figure below. Deploying Microsoft Windows Clustering in an iSCSI SAN 26 Network Connections – Advanced Settings 4. If you are using multipath I/O, in the Cluster Administrator, right-click the network name that represents your SAN network and select Properties. If you are not using multipath I/O, you have completed the network configuration modifications. Cluster Administrator – Network Properties In the Network Properties dialog box, uncheck the box Enable this network for cluster use. This will allow multipath I/O to control the link failover for the SAN interfaces. Deploying Microsoft Windows Clustering in an iSCSI SAN 27 Cluster Administrator – SAN Network Properties for Multipath I/O Note: If all the redundant network connections fail on the node that is controlling the cluster, services will fail over to another node. This is because the cluster cannot reach the backend PS Series storage. It is recommended that you test multipath I/O failover. On a cluster node, unplug one of the network cables that connects to the SAN network. You should still maintain connectivity to the PS Series storage. Adding a Node to the Cluster Once you complete the initial cluster setup on the first node (Node A) and modify the cluster network configuration, you must add at least one other node (Node B) to the cluster to create a failover partner. Windows Server 2003 allows you to have up to eight nodes in one cluster, when using iSCSI disks for shared storage. The node must be connected to the shared volumes, as described in Connecting Nodes to Volumes. However, do not align disk sectors or format the disks. To add a node to your cluster, follow these steps. 1. Using the Cluster Administrator, click File > New > Node. This will launch the Add Nodes Wizard. Click Next to continue. Deploying Microsoft Windows Clustering in an iSCSI SAN 28 Add Nodes Wizard 2. In the Select Computers dialog box, specify the node you want to add to the cluster in the Computer name field. You can either type the name or click Browse to locate the node. Once you specify the node, click Add to move it into the Selected computers list. Then, click Advanced. Add Nodes Wizard – Select Computers Deploying Microsoft Windows Clustering in an iSCSI SAN 29 3. Since the first cluster node (Node A) already has control of the cluster resources, specify that the new node (Node B) should not connect to the resources. In the Advanced Configuration Options dialog box, select Advanced (minimal) configuration. Then, click OK to return to the Select Computers dialog box and click Next to continue. Figure 27: Advanced Configuration Options 4. The Add Nodes Wizard will analyze the node configuration, displaying progress as shown in the following figure. If errors are found, a condition will be flagged. You can expand the failed object to obtain the details needed to correct the problem. If there are no critical errors that prevent the wizard from continuing the configuration, click Next to continue. Add Nodes Wizard – Analyzing the Configuration Deploying Microsoft Windows Clustering in an iSCSI SAN 30 5. In the Cluster Service Account dialog box, enter the password for the cluster service account that you specified for the first node in Creating the Cluster, Step 7. The User name field will already be filled in and cannot be changed. Click Next to continue. Add Nodes Wizard – Cluster Service Account 6. The Proposed Cluster Configuration dialog box appears. Review the configuration. Click Next to continue. Add Nodes Wizard – Proposed Cluster Configuration Deploying Microsoft Windows Clustering in an iSCSI SAN 31 7. The wizard will start to add the node to the cluster. The Adding Nodes to the Cluster dialog box appears, showing the progress. If errors are found, a condition will be flagged. You can expand the failed object to obtain the details needed to correct the problem. If no errors occur that would prevent the wizard from completing the configuration, click Next to continue. Add Nodes Wizard – Adding Nodes to the Cluster 8. Once the wizard completes the new cluster node configuration, the wizard will notify you that the addition was successful and give you the option to view the log. To exit, click Finish. Add Nodes Wizard – Completion Deploying Microsoft Windows Clustering in an iSCSI SAN 32 9. As described in Modifying the Cluster Network Configuration, Step 3, reorder the bind preference for the new cluster node’s network adapters. Use the following order: a. External public network b. Internal private network (Heartbeat) c. SAN network On the new cluster node (Node B), click Start > Control Panel > Network Connections. From the menu bar, select Advanced > Advanced Settings. Use the arrow keys on the right to reorder the adapter list. Modifying Cluster Configuration Options Cluster configuration modifications that are recommended by Microsoft include the following: • Specify the preferred owners of a cluster group. • Specify the restart policy for a resource. • Specify which nodes can own a resource. These options are unique to every cluster implementation. For detailed information, see the Microsoft TechNet article Planning and preparing for cluster installation which can be found at the following location: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/f5abf1f91d84-4088-ae54-06da05ac9cb4.mspx Installing Cluster Applications Once the cluster is configured, install the service applications (for example, Exchange or SQL Server) on the cluster nodes and configure them to use the shared PS Series volumes for storage. For information about installing and configuring applications in a cluster, see the application vendor documentation. Testing Cluster Failover It is recommended that you ensure that cluster services can fail over in the event of a failure. To test the cluster, use the Cluster Administrator to move resource groups from one node to another. Perform these steps using the Cluster Administrator: 1. Expand Groups in the left panel. 2. Select the first group object. The node that owns the object will appear in the right panel. Deploying Microsoft Windows Clustering in an iSCSI SAN 33 3. Right-click the first group object and select Move Group, as shown in the figure below. Cluster Administrator – Moving a Group If the failover succeeds, the Cluster Administrator will show the change of owner in the right panel, as shown in the following figure. Cluster Administrator – Owner Change 4. Repeat the previous steps for each group object. You can also verify your cluster setup with the Cluster Diagnostics and Verification Tool (ClusDiag.exe) which is available at the following location: http://www.microsoft.com/downloads/details.aspx?familyid=b898f587-88c3-4602-84deb9bc63f02825&displaylang=en Deploying Microsoft Windows Clustering in an iSCSI SAN 34 Expanding SAN Storage Online As the storage requirements increase for the cluster applications and users, you can easily expand individual PS Series volumes and SAN capacity, online and without disruption. You can increase the size of a PS Series group volume by using the Group Manager GUI or CLI. You must then enable Windows to recognize the size change. For more information, see Increasing the Size of a PS Series Volume. If you need more SAN capacity to accommodate new volumes or expanded volumes, you can add more members to the PS Series group. See Increasing PS Series Group Capacity for more information. Increasing the Size of a PS Series Volume You can use the Group Manager GUI or CLI to increase the size of a PS Series volume without disrupting users. You do not need to reboot servers, and the space will be immediately available. Follow these steps to use the Group Manager GUI to increase the size of a volume: 1. Expand Volumes in the far left panel, and select the volume name. 2. In the Activities panel of the window that appears, click Modify volume settings. In the Modify Volume Settings window, verify that the “Free group space” displayed in the Space utilization table is larger than the desired expansion size. 3. Specify the new volume size, as shown in the figure below. When finished, click OK. Group Manager – Modify Volume Settings Deploying Microsoft Windows Clustering in an iSCSI SAN 35 To enable Windows Server 2003 to recognize the volume size increase, you must rescan the disks in the Disk Management utility and then use the DiskPart utility. For more information, see the Technical Report Microsoft Windows: Expanding Basic Disk Volumes on the EqualLogic Customer Support website. Note: In a cluster environment, when you expand iSCSI disks, you need to run the DiskPart utility from the cluster node that is controlling the cluster. Standby cluster nodes report iSCSI disks as “Unknown” and “Unreadable” because they do not have control of the disk resource. However, those nodes will still see the volume extended. Increasing PS Series Group Capacity If additional PS Series group storage capacity is needed in order to create more volumes or expand volumes, you can add more members (arrays) to the group. First, set up the hardware for the new PS Series storage array. Then, run setup. When prompted for the PS Series group to join, specify the group name and IP address. For complete array setup and member configuration instructions, see the PS Series QuickStart or the Group Administration manual. Once the array has been added to the group, volume data will be load balanced across all the group members and the group capacity expanded. You can then add new volumes or increase the size of existing volumes. Strategies for Backup and Recovery To ensure high availability for your cluster nodes, you need to be aware of the specific areas that require backup protection and the solutions available. The following sections address these areas and present possible solutions. Protecting Cluster Data There are four specific areas to protect with backups to ensure high availability for your cluster nodes: • Cluster disk signatures and partitions. Before you begin to backup any data on the cluster nodes, make sure you backup the cluster disk signatures and partitions using the Automated System Recovery in the Backup Wizard for Windows. If you later need to restore the signature of the quorum disk, it will be critical to have a copy from which to restore. For example, you will need to restore the signature of the quorum disk if you experience a complete system failure and the signature of the quorum disk changed since the last backup. • Cluster quorum resource. When you backup data on a cluster node, make sure you also backup the quorum resource. The quorum resource is important because it contains the current cluster configuration, application registry checkpoints, and the cluster recovery log. Deploying Microsoft Windows Clustering in an iSCSI SAN 36 • Shared disks. To back up all shared disks owned by a node, perform a full backup from that node. If a shared disk owned by the node that is being backed up fails over to another node during the backup process, the backup set will not contain a full backup of that disk. • Data on the individual cluster nodes. After you back up the quorum resource on one node, it is not necessary to back up the quorum resource on the remaining cluster nodes. However, you may want to back up the clustering software, cluster administrative software, system state, and application data on the remaining nodes. Note: If you back up the system state for a node, you will also automatically back up the quorum data if the cluster service is running on that node. Choosing a Backup Method There are many ways to backup cluster data. For example, you can follow the steps in the Microsoft TechNet article Backing up and restoring server clusters to backup cluster data using the Microsoft Backup utility, NTBackup: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/c9fe11a997c0-496a-9223-ed4b77786368.mspx Alternately, to backup cluster data, you can use a backup application from the vendor of your choice. Consider the following when choosing a backup application: • Verify that the backup application is capable of acting as a VSS requestor, so you can use VSS backups. Backup applications that support VSS and can be used as a VSS requestor include the following: − VERITAS™ Backup Exec™ − CommVault® Galaxy™ Backup & Recovery − CA BrightStor® ARCserve® Backup − Bakbone® NetVault − Legato® NetWorker • Cluster backup software should be “cluster aware.” This means the software should use cluster APIs and be able to gracefully deal with the failover of a disk resource during the backup process. • Make sure that your backup application will be compatible with the version of the Windows operating system installed on the cluster nodes. Another method of protecting Windows Server 2003 data is by using a near-continuous backup and archiving solution that unifies data protection, disaster recovery, and archiving. This type of solution provides immediate recovery, file, e-mail, or, database storage optimization, instant user access, and regulatory compliance in a Windows Server 2003 environment. You can maintain copies of Windows Server 2003 data on a separate server and continuously update these copies as the data changes. If a catastrophic failure occurs, the data loss is zero or at most a few minutes. Deploying Microsoft Windows Clustering in an iSCSI SAN 37 Backup applications that support near-continuous backup and archiving fall under different categories and include the following: • Microsoft Data Protection Manager – DPM is a server software application that optimizes diskbased backup and recovery. It provides continuous data protection for file servers. http://www.microsoft.com/windowsserversystem/dpm/default.mspx Also see the Deploying Microsoft® System Center Data Protection Manager 2006 in an iSCSI SAN technical report on the EqualLogic Support web site. • Mimosa NearPoint™ for Microsoft Exchange Server – Unifies data protection, disaster recovery, mailbox extension and archiving in a single solution, assuring immediate recovery, email storage optimization, fingertip user access, and regulatory compliance for the world’s most popular e-mail environment. http://www.mimosasystems.com/html/prod_nearpoint.htm • Veritas® (Symantec®) Panther – Provides continuous data protection solution that also contains web-based end user file recovery functionality. This product can stand alone or integrate with Backup Exec™ for Windows Server. http://www.veritas.com/Products/www?c=product&refId=449 • Sonasoft™ – Provides reliable disaster recovery capabilities. SonaSafe for SQL Server provides intelligent Standby capabilities. SonaSafe for Exchange Server provides intelligent, brick-level backup and recovery. SonaSafe for File Systems provides bare metal recovery and open file backup/recovery and reliable image level backup capabilities. http://www.sonasoft.com • LiveVault® – Provides a disk-based, online backup and recovery solution. Both products InSync and InControl are disk-to-disk solutions for businesses with remote offices. http://www.livevault.com/solutions/solutions_overview.aspx Restoring Data When restoring cluster data, there are several areas on which to focus: • Cluster database. If the signature of the quorum disk has changed since you last backed up data, instead of restoring the System State only, use Automated System Recovery in the Backup or Restore Wizard to restore the quorum disk signature along with the System State. Follow the recommended Microsoft procedure described in the TechNet article Restore the cluster database on a local node: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/c9fe1 1a9-97c0-496a-9223-ed4b77786368.mspx Deploying Microsoft Windows Clustering in an iSCSI SAN 38 • Quorum resource. Restoring will require stopping the cluster service on all remaining cluster nodes after the node that was restored reboots. The entire cluster will therefore be unavailable while the restored quorum data is copied to the quorum disk and the other nodes in the cluster. Follow the recommended Microsoft procedure described in the TechNet article Restore the contents of a cluster quorum disk for all nodes in a cluster: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/c9fe1 1a9-97c0-496a-9223-ed4b77786368.mspx • Cluster node volumes. Using your backup application, perform a restore of the required data. There are many options you can use to restore data. You can restore from a snapshot, restore from a tape, or restore from backup-to-disk media. Choose the option appropriate for your situation. EqualLogic has many Technical Reports on performing backup and restore operations using a PS Series group and various backup applications. See the EqualLogic Customer Support website for more information. SAN and Network Upgrades A properly configured cluster will have no shared hardware components. This will enable you to recover from the failure of almost any component in your cluster configuration. However, you are most likely to encounter a situation where you will need to upgrade some component of your cluster. This could be a cluster node, a component in a node, or a segment of a network. When you need to upgrade a component in a cluster node, first use the Cluster Administrator to determine if the node has control of the cluster resources. If the node has control of the cluster resources, use the Cluster Administrator to fail over the resources to another node. Once you have moved the resources from the node, you should then pause the node. At this point, you can safely perform work on that node. Use this same process if you need to perform maintenance on a network switch, because a switch failure is equivalent to a link failure. You should also consider a situation in which you will need to update the firmware on the PS Series storage arrays in the group. When updating firmware on an array, you will need to restart the array. This will cause a service interruption for any application using the volumes stored on the array, because the volumes will be unavailable for the time that it takes the array to restart. See the PS Series Release Notes for detailed information about updating PS Series firmware. Cluster Maintenance The following sections describe two common cluster maintenance issues: how to replace a quorum disk that has failed and how to remove a node from a cluster. Replacing the Quorum Resource If access to the shared quorum resource fails or if the PS Series volume associated with the quorum resource fails, the cluster will crash. Although the cluster service will attempt multiple restarts, the cluster will not respond until the resource is replaced. Deploying Microsoft Windows Clustering in an iSCSI SAN 39 You can replace a failed quorum disk using the following procedure: 1. In the PS Series group, create a new volume for the quorum resource. Apply the same access control record settings as for the failed quorum volume. See Configuring PS Series Volumes for more information. 2. On each cluster node, set the cluster service to manual to prevent repetitive restarts. 3. On the first node (Node A), use the iSCSI initiator to log in to the new quorum volume. Remember to make the connection persistent and to bind the connection. See Connecting Nodes to Volumes for information. 4. Align the disk sectors, as described in Aligning Disk Sectors, and configure as a basic disk, as described in Configuring a Basic Disk. 5. On Node A, using the Disk Management utility, create a single NTFS partition on the new quorum disk and assign a different drive letter from that of the original quorum resource. See Assigning a Drive Letter and Formatting a Partition for more information. 6. On Node A, open a command prompt and start the cluster service in fixquorum mode, using the net start clussvc /fixquorum command. Fix Cluster Quorum 7. Once the cluster service has started on Node A, launch the Cluster Administrator and connect to Node A. Do not connect to the cluster alias name. Open the Cluster Administrator and click File > Close. This will disconnect you from the cluster virtual name. Then, connect to Node A by clicking File > Open Connection. In the Open Connection to Cluster dialog box, enter the node name in the Cluster or server name field. Open Connection to Cluster Deploying Microsoft Windows Clustering in an iSCSI SAN 40 8. On Node A, within the Cluster Group, create a new physical disk resource using the new quorum resource created in Step 1. Bring this disk online. 9. On Node A, in the Cluster Administrator, perform the following steps: a. Right-click the cluster name and select Properties. Ignore the error messages concerning the failed quorum partition. b. Click the Quorum tab and, from the Quorum resource pull-down menu, select the new iSCSI disk for the quorum resource and apply the changes. 10. On Node A, stop the cluster service. 11. On the second node (Node B), use the iSCSI initiator to log in to the iSCSI target for the new quorum resource. Remember to make the connection persistent and to bind the connection. 12. Starting with Node A, restart the cluster service on both nodes. 13. On Node A, from the Cluster Administrator and within the Cluster Group, delete the old quorum resource. 14. On Node A and Node B, set the cluster service to automatic. Removing a Node from a Cluster You may encounter a situation in which you need to remove a node from a cluster (for example, if you want to upgrade a cluster node with a new computer). To remove a node from a cluster, follow these steps: 1. Start the Cluster Administrator. 2. Right-click the node you want to remove and click Stop Cluster service. Note: Do not perform this step if this server is the last node in the cluster. Right-click the node you want to remove and click Evict Node, as shown in the figure below. This returns the cluster to its original unconfigured state. You can add it again later to the same cluster or to a different cluster. Deploying Microsoft Windows Clustering in an iSCSI SAN 41 Cluster Administrator – Evict Node If you cannot start the cluster service or if you have trouble removing the node, you can manually unconfigure the cluster service on a node as follows: 1. On the node you want to remove, open a command prompt. Click Start > Run. Then, enter cmd. 2. At the command prompt, enter cluster node /forcecleanup. Note: If the cluster service does not exist in the registry, the command will not respond. To create a place holder, enter sc create clussvc at the command line. Using WSRM and Scripts to Manage Clusters Microsoft released the Windows Server Resource Manager (WSRM) as a feature in Windows Server 2003 Datacenter Edition and Windows Server 2003 Enterprise Edition. By using WSRM to manage a cluster deployment, you gain more control over node resource usage during failover. In addition, depending on specific events or the current state of the cluster, you can also use WSRM to activate specific resource allocation policies. The use of WSRM is outside the scope of this paper. To fully utilize WSRM, read the Microsoft Download Center article Using WSRM and Scripts to Manage Clusters at the following location: http://www.microsoft.com/downloads/details.aspx?FamilyID=ba2559e6-dd23-41a6-9efb1d90f8f1fc17&displaylang=en Deploying Microsoft Windows Clustering in an iSCSI SAN 42 Migrating an Existing Cluster to PS Series Storage Not all cluster implementations will be new implementations. Many situations will require migrating data from an e-mail store, relational database, or file share to a new shared storage device. When moving an existing cluster storage infrastructure to a PS Series group, you will follow the same steps as you would any other data migration. The basic steps are as follows: 1. Create a back-out plan. The first step in any migration is to have a back-out plan in place. If, for whatever reason, something unexpected causes your migration to fail, you will need to be able to bring the old system back online to service your customers or users. Planning and documenting how you will revert back to the old system will give you the best chance of a quick recovery. 2. Perform a full backup of your data on the existing cluster. As with any mission critical application that will have its configuration modified, it is strongly recommended that you perform a complete backup of all data, databases, and logs before migrating to a new system or cluster. 3. Copy the existing cluster data from the current storage to volumes in a PS Series group. When performing the migration, you should have exclusive access to the data, databases, and logs being moved. This will help prevent open file locks. You can move data in several different ways. For example, you can: • Drag and drop files using Windows Explorer. • Backup to a tape library and restore to PS Series volumes. The method you use depends on the application whose data you are migrating. Moving a user file share will be much simpler than migrating a large relational database. Many vendors will have suggestions in their documentation for moving the application’s data repository. 4. Bring the cluster online using the new data locations. Once you have successfully migrated your data, databases, or logs to the PS Series group, bring the cluster online, specifying the new location for the quorum resource and service data, as needed. Verify that all cluster groups and resources come online. 5. Test the cluster. Testing the cluster can be broken down into the following parts: a. First, test the application that will be running on the cluster. This may include sending and receiving e-mail, writing transactions into a database, or reading and writing files to a network share. Verify that you can perform the same tasks using the data in the PS Series group as you did using the data in the previous location. b. Second, perform a failover test of the cluster from one node to another. Again, verify that all cluster groups and resources come online. A thorough test of your new cluster before putting it into production will ensure a smooth transition. 6. Retain the old cluster data. Some organizations prefer to leave the old storage infrastructure up and running for a period of time as a fallback measure. The old cluster data may be accessible only to administrators. Deploying Microsoft Windows Clustering in an iSCSI SAN 43 More Information and Customer Support Visit the EqualLogic Customer Support website, where you can download the latest documentation and firmware for PS Series storage arrays. You can also view FAQs, the Knowledge Base, and the Tech Reports and submit a service request. EqualLogic PS Series storage array documentation includes the following: • Release Notes. Provides the latest information about PS Series storage arrays. • QuickStart. Describes how to set up the hardware and start using PS Series storage arrays. • Group Administration. Describes how to use the Group Manager GUI to manage a PS Series group. This manual provides comprehensive information about product concepts and procedures. • CLI Reference. Describes how to use the Group Manager command line interface to manage a group and individual arrays. • Hardware Maintenance. Provides information on maintaining the PS Series storage array hardware. To access the Customer Support website, from the EqualLogic website, www.equallogic.com, click Support and log in to a support account. If you do not have an account, create one by clicking the link under the login prompt. To contact customer support, send e-mail to [email protected]. If the issue is urgent, call 1-877-887-7337 to speak with a member of the customer support team. Deploying Microsoft Windows Clustering in an iSCSI SAN 44