Khám phá windowns server 2008 - p 39 ppt

ptg6432687 360 12 Application-Level Failover and Disaster Recovery in a Hyper-V Environment All storage drivers must be digitally signed and certified for use with Windows Server 2008. Many storage devices certified for Windows Server 2003 may not work with Windows Server 2008 and either simply cannot be used for failover cluster shared storage or may require a firmware and driver upgrade to be supported. One main reason for this is the fact that all failover shared storage must comply with SCSI-3 architecture model SAM- 2. This includes any and all legacy and SAS controllers, fiber host bus adapters, and iSCSI hardware- and software-based initiators and targets. If the cluster attempts to perform an action on a LUN or shared disk and the attempt causes an interruption in communication to the other nodes in the cluster or any other system connected to the shared storage device, data corruption can occur, and the entire cluster and each SAN-connected system may be lose connectivity to the storage. When LUNS are presented to failover cluster nodes, each LUN must be presented to each node in the cluster. Also, when the shared storage is accessed by the cluster and other systems, the LUNs must be masked or presented only to the cluster nodes and the shared storage device controllers to ensure that no other systems can access or disrupt the cluster communication. There are strict requirements for shared storage support, especially with failover clusters. Storage area networks (SANs) or other types of shared storage must meet the following requirements: . All fiber, SAS, and iSCSI host bus adapters (HBAs) and Ethernet cards used with iSCSI software initiators must have (or obtain) the Designed for Microsoft Windows logo for Windows Server 2008 and have suitable signed device drivers. . SAS, fiber, and iSCSI HBAs must use StorPort device drivers to provide targeted LUN resets and other functions inherent to the StorPort driver specification. SCSIport was at one point supported for two-node clusters, but if a StorPort driver is available it should be used to ensure support from the hardware vendors and Microsoft. . All shared-storage HBAs and backend storage devices, including iSCSI targets, fiber, and SAS storage arrays, must support SCSI-3 standards and must also support persis- tent bindings or reservations of LUNs. . All shared-storage HBAs must be deployed with matching firmware and driver versions. Failover clusters using shared storage require a stable infrastructure, and applying the latest storage controller driver to outdated HBA firmware can cause undesirable situations and may disrupt data access. . All nodes in the cluster should contain the same HBAs and use the same version of drivers and firmware. Each cluster node should be an exact duplicate of each other node when it comes to hardware selection, configuration, and driver and firmware revisions. This allows for a more reliable configuration and simplifies management and standardization. . When iSCSI software initiators are used to connect to iSCSI software- or hardware- based targets, the network adapter used for iSCSI communication must be connected to a dedicated switch, cannot be used for any cluster communication, and cannot be a teamed network adapter. Download at www.wowebook.com ptg6432687 361 Overview of Failover Clustering in a Hyper-V Host Environment In addition, for Microsoft to officially support failover clusters and shared storage, the entire configuration must be tested as a whole system before it will be considered a “Windows Server 2008 Failover Cluster Supported Configuration.” The whole system includes the server brand and model, local disk configuration, HBA, and network card controller firmware and driver version (and, if applicable, iSCSI software initiator software, storage array, and storage array controller firmware or SAN operating system version). The point to keep in mind is that if a company really wants to consider using failover clusters, they should research and find a suitable solution to meet their budget. If a tested and supported solution cannot be found within their price range, they should consider alternative solutions that can restore systems in about an hour or a few hours (if they cannot budget for a restore that takes just a few minutes). The truth is that failover clus- ters are not for everyone, they are not for the faint of heart, and they are not within every organization’s IT budget. Even after reading all this, some administrators will still want to deploy test failover cluster configurations to gain knowledge and experience with the features and functional- ity. They will want to learn how to deploy and how to manage failover clusters, and they will want to learn how to train staff and present prototype solutions to management. For those administrators, various low-cost shared-storage alternatives are available, including the Windows iSCSI initiator and a software-based iSCSI target. In case a problem is encountered or data is lost or corrupted, be aware that these are not supported by Microsoft. SAS Storage Arrays Serial Attached SCSI disks are one of the newest additions to the disk market. SAS storage arrays can provide organizations with affordable entry-level hardware-based direct attached storage arrays suitable for Windows Server 2008 clusters. SAS storage arrays are commonly limited to four hosts, but some models support extenders to add additional hosts as required. One of the major issues with direct attached storage (not with SAS) is that replication of the data within the storage is usually not achievable without involving one of the host systems and software. Fiber Channel Storage Arrays With Fiber Channel (FC) HBAs, Windows Server 2008 can access both shared and nonshared disks residing on a SAN connected to a common FC switch. This allows both the shared-storage and operating system volumes to be located on the SAN, if desired, to provide diskless servers. In many cases, however, diskless storage may not be desirable if the operating system performs many paging actions, because the cache on the storage controllers can be used up very fast and can cause delay in disk read and write operations for dedicated cluster storage. If this is desired, however, the SAN must support this option and be configured to present the OS-dedicated LUNs to only a single host exclusively. The LUNs defined for shared cluster storage must be zones and presented to every node in the cluster, and to no other systems. In many cases, the LUN zoning or masking is configured on the fiber switch that connects the cluster nodes and the shared-storage device. This is a distinct difference between direct access storage and FC or iSCSI shared storage. Both FC 12 Download at www.wowebook.com ptg6432687 362 12 Application-Level Failover and Disaster Recovery in a Hyper-V Environment and iSCSI require a common fiber or Ethernet switch to establish and maintain connec- tions between the hosts and the storage. A properly configured FC zone for a cluster will include the World Wide Port Number (WWPN) of each cluster host’s FC HBAs and the WWPN of the HBA controllers from the shared-storage device. If either the server or the storage device uses multiple HBAs to connect to a single or multiple FC switches to provide failover or load balancing function- ality, this is known as multipath I/O (MPIO), and a qualified driver for MPIO management and communication must be used. Also, the function of either MPIO failover or MPIO load balancing must be verified as approved for Windows Server 2008. Consult the shared- storage vendor (including the fiber switch vendor) for documentation and supported configurations. In addition, check the cluster hardware compatibility list (HCL) on the Microsoft website to find approved configurations. iSCSI Storage When organizations want to use iSCSI storage for Windows Server 2008 failover clusters, security and network isolation is highly recommended. iSCSI uses an initiator or the host that requires access to the LUNs or iSCSI targets. Targets are located or hosted on iSCSI target portals. Using the target portal interface, you must configure the target to be accessed by multiple initiators in a cluster configuration. Both the iSCSI initiators and target portals come in software- and hardware-based models, but both models use IP networks for communication between the initiators and the targets. The targets will need to be presented to Windows as a basic disk. When standard network cards will be used for iSCSI communication on Windows Server 2008 systems, the built-in Windows Server 2008 iSCSI initiator can be used, as long as the iSCSI target can support the authentication and security options provided, if used. Regardless of whether you choose the Microsoft iSCSI initiator of software-based or hard- ware-based initiators or targets, iSCSI communication should be deployed on isolated network segments and preferably dedicated network switches. Furthermore, the LUNs presented to the failover cluster should be masked from any systems that are not nodes participating in the cluster by using authentication and IPsec communication as possible. Within the Windows Server 2008 operating system, the iSCSI HBA or designated network card should not be used for any failover cluster configuration and cannot be deployed using network teaming software, or it will not be supported by Microsoft. By now, you should understand that Microsoft wants to support only those organizations that deploy failover clusters on tested and approved entire systems. In many cases, however, failover clusters can still be deployed and will function; after all, you can use the Create a Cluster Wizard to deploy a cluster that is not in a supported configuration. NOTE When deploying a failover cluster, pay close attention to the results of the Validate a Cluster Wizard to ensure that the system has passed all storage tests to ensure a sup- ported configuration is deployed. Download at www.wowebook.com ptg6432687 363 Deploying a Failover Cluster for Hyper-V Hosts Multipath I/O Windows Server 2008 supports multipath I/O to external storage devices such as SANs and iSCSI targets when multiple HBAs are used in the local system or by the shared storage. MPIO can be used to provide failover access to disk storage in case of a controller or HBA failure, but some drivers also support load balancing across HBAs in both standalone and failover cluster deployments. Windows Server 2008 provides a built-in MPIO driver that can be leveraged when the manufacturer conforms to the necessary specifications to allow for the use of this built-in driver. Volume Shadow Copy for Shared Storage Volume The Volume Shadow Copy Service (VSS) is supported on shared-storage volumes. VSS can take a point-in-time snapshot of an entire volume, enabling administrators and users to recover data from a previous version. Furthermore, failover clusters and the entire Windows backup architecture use VSS to store backup data. Many of today’s services and applications that are certified to work on Windows Server 2008 failover clusters are VSS compliant, and careful consideration should be made when choosing an alternative backup system, unless the system is provided by the shared-storage manufacture and certi- fied to work in conjunction with VSS, Windows Server 2008, and the service or applica- tion running on the failover cluster. Failover Cluster Node Operating System Selection Hyper-V requires the 64-bit version of Windows Server 2008 to run on the host server. To do host-level failover clustering, the version of 64-bit Windows 2008 must be either the Enterprise Edition or the Datacenter Edition. Deploying a Failover Cluster for Hyper-V Hosts The Windows Server 2008 failover cluster feature is not installed on a Hyper-V host system by default and must be installed before failover clusters can be deployed. Alternatively, for administrative workstations, the remote server management features can be installed, which will include the Failover Cluster Management snap-in, but the feature will need to be installed on all nodes that will participate in the failover cluster. Even before installing the failover cluster features, several steps should be taken on each node of the cluster to help deploy a reliable failover cluster. Before deploying a failover cluster, perform the following steps on each node that will be a member of the failover cluster: . Configure fault-tolerant volumes or LUNS using local disks or SAN attached storage for the operating system volume. . Configure at least two network cards, one for client and cluster communication and one for dedicated cluster communication. 12 Download at www.wowebook.com ptg6432687 364 12 Application-Level Failover and Disaster Recovery in a Hyper-V Environment . For iSCSI shared storage, configure an additional, dedicated network adapter or hard- ware-based iSCSI HBA. . Rename each network card properties for easy identification within the Cluster Management console after the failover cluster is created. For example, rename Local Area Connection to PUBLIC and Local Area Connection 2 to iSCSI and Local Area Connection 3 to HEARTBEAT, as required and possible. Also, if network teaming will be used, configure the team first, excluding teaming from iSCSI connections, and rename each physical network adapter in the team to TEAMMEMBER1 and 2. The virtual team adapter should then get the name of PUBLIC or HEARTBEAT. . Configure all necessary IPv4 and IPv6 addresses as static configurations. . Verify that any and all HBAs and other storage controllers are running the proper firmware and matched driver version suitable for Windows Server 2008 failover clus- ters. . If shared storage will be used, plan to use at least two separate LUNs, one to serve as the witness disk and one to serve as the cluster disk for a high-availability service or application group. . If applications or services not included with Windows Server 2008 will be deployed in the failover cluster, as a best practice, add an additional fault-tolerant array or LUN to the system to store the application installation and service files. . Ensure that proper LUN masking and zoning has been configured at the FC or Ethernet switch level for FC or iSCSI shared-storage communication, suitable for failover clustering. Each node in the failover cluster, along with the HBAs of the shared storage device, should have exclusive access to the LUNs presented to the failover cluster. . If multiple HBAs will be used in each failover node or in the shared-storage device, ensure that a suitable MPIO driver has been installed. The Microsoft Windows Server 2008 MPIO feature can be used to provide this function if approved by the HBA, switch, and storage device vendors and Microsoft. . Shut down all nodes except one; and on that node configure the shared-storage LUNS as Windows basic disks, format as a single partition/volume for the entire span of the disk, and define an appropriate drive letter and volume label. Shut down the node used to set up the disks and bring each other node up one at a time and verify that each LUN is available. If necessary, configure the appropriate drive letter if it does not match what was configured on the first node. . As required, test MPIO for load balancing and failover using the appropriate diagnos- tic or monitoring tool to ensure proper operation on each node one at a time. . Designate a domain user account to be used for failover cluster management, and add this account to the local Administrators group on each cluster node. In the domain, grant this account the Create Computer Accounts right at the domain level to ensure that when the administrative and high-availability “service or application” groups are created, the account can create the necessary domain computer accounts. Download at www.wowebook.com ptg6432687 365 Deploying a Failover Cluster for Hyper-V Hosts . Create a spreadsheet with the network names, IP addresses, and cluster disks that will be used for the administrative cluster and the high-availability “service or appli- cation” group or groups that will be deployed in the failover cluster. Each service or application group will require a separate network name and IPv4 address. If IPv6 is used, the address can be added separately in addition to the IPv4 address or a custom or generic service or application group will need to be created. . Probably most important, install the Hyper-V role on the server so that the server system is ready and configured to be a Hyper-V host server. See Chapter 4, “Installing Windows 2008 Server and the Hyper-V Role,” for instructions about installing the Hyper-V role and making sure the Hyper-V host is working properly before proceeding with the cluster configuration. After completing the tasks in the preceding list, you can install the failover cluster. Failover clusters are deployed as follows: 1. Preconfigure the nodes, as listed previously. 2. Install the failover cluster feature. 3. Run the Validate a Configuration Wizard and review the results to ensure that all tests pass successfully. If any tests fail, the configuration will not be supported by Microsoft and can be prone to several different types of issues and instability. 4. Run the Create a Cluster Wizard to actually deploy the administrative cluster. 5. Customize the failover cluster properties. 6. Run the High Availability Wizard to create a high-availability service or application group within the failover cluster for the Hyper-V virtualization role. 7. Test the failover cluster configuration, and back it up. Installing the Failover Cluster Feature on a Hyper-V Host Before a failover cluster can be deployed, the necessary feature must be installed. To install the failover cluster feature, perform the following steps: 1. Log on to the Windows Server 2008 cluster node with an account with administrator privileges. 2. Click Start, All Programs, Administrative Tools, and select Server Manager. 3. When Server Manager opens, in the tree pane select the Features node. 4. In the Tasks pane, click the Add Features link. 5. In the Add Features window, select Failover Clustering and click Next. 6. When the installation completes, click the Close button to complete the installation and return to Server Manager. 7. Close Server Manager and install the Failover Cluster feature on each of the remain- ing cluster nodes. 12 Download at www.wowebook.com ptg6432687 366 12 Application-Level Failover and Disaster Recovery in a Hyper-V Environment FIGURE 12.1 Adding the servers to be validated by the Validate a Configuration Wizard. Running the Validate a Configuration Wizard Failover cluster management is the new MMC snap-in used to administer the failover cluster feature. After the feature is installed, the next step is to run the Validate a Configuration Wizard from the Tasks pane of the Failover Cluster Management console. All nodes should be up and running when the wizard is run. To run the Validate a Configuration Wizard, perform the following steps: 1. Log on to one of the Windows Server 2008 cluster nodes with an account with administrator privileges over all nodes in the cluster. 2. Click Start, All Programs, Administrative Tools, and select Failover Cluster Management. 3. When the Failover Cluster Management console opens, click the Validate a Configuration link or the Actions Pane. 4. When the Validate a Configuration Wizard opens, click Next on the Before You Begin page. 5. In the Select Servers or a Cluster page, enter the name of a cluster node and click the Add button. Repeat this process until all nodes are added to the list, as shown in Figure 12.1, and click Next to continue. 6. In the Testing Options page, read the details that explain the requirements for all tests to pass to be supported by Microsoft. Select the Run All Tests (Recommended) radio button, and then click Next to continue. 7. In the Confirmation page, review the list of servers that will be tested and the list of tests that will be performed, and then click Next to begin the testing the servers. 8. When the tests complete, the Summary window will display the results and whether the tests pass, as shown in Figure 12.2. Click Finish to complete the Validate a Download at www.wowebook.com ptg6432687 367 Deploying a Failover Cluster for Hyper-V Hosts 12 FIGURE 12.2 Successful result of the Validate a Configuration Wizard is required for Microsoft failover cluster support. Configuration Wizard. If the test failed, click the View Report button to review detailed results and determine which test failed and why. Even if the Validate a Configuration Wizard does not pass every test, you may still be able to create a cluster (depending on the test). After the Validation a Configuration Wizard is completed successfully, the cluster can be created. Creating the Hyper-V Host Failover Cluster When the Hyper-V host failover cluster is first created, all nodes in the cluster should be up and running. The exception to that rule is when failover clusters use direct attached storage such as SAS devices that require a process of creating the cluster on a single node and adding other nodes one at a time. For clusters that will not use shared storage or clus- ters that will connect to shared storage using iSCSI or Fiber Channel connections, all nodes should be powered on during cluster creation. To create the failover cluster, complete the following steps: 1. Log on to one of the Windows Server 2008 cluster nodes with an account with administrator privileges over all nodes in the cluster. 2. Click Start, All Programs, Administrative Tools, and select Failover Cluster Management. 3. When the Failover Cluster Management console opens, click the Create a Cluster link the Actions pane. 4. When the Create Cluster Wizard opens, click Next on the Before You Begin page. 5. In the Select Servers page, enter the name of each cluster node and click Add. When all the nodes are listed, click the Next button to continue. Download at www.wowebook.com ptg6432687 368 12 Application-Level Failover and Disaster Recovery in a Hyper-V Environment FIGURE 12.3 Defining the network name and IPv4 address for the failover cluster. 6. In the Access Point for Administering the Cluster page, type in the name of the cluster and complete the IPv4 address and click Next, as shown in Figure 12.3. 7. In the Confirmation page, review the settings, and then click Next to create the cluster. 8. In the Summary page, review the results of the cluster-creation process and click Finish to return to the Failover Cluster Management console. If there are any errors, you can click the View Report button to reveal the detailed cluster-creation report. 9. Back in the Failover Cluster Management console, select the cluster name in the tree pane. In the Tasks pane, review the configuration of the cluster. 10. In the tree pane, select and expand Nodes to list all the cluster nodes. 11. Select Storage and review the cluster storage in the Tasks pane listed under Summary of Storage, as shown in Figure 12.4. 12. Expand Networks in the tree pane to review the list of networks. Select each network and review the names of the adapters in each network. 13. After confirming that the cluster is complete, close the Failover Cluster Management console and log off of the cluster node. After the cluster has been created, you should use the High Availability Wizard to perform additional tasks before creating any service or application groups. These tasks can include, but may not require, customizing the cluster networks, adding storage to the cluster, adding nodes to the cluster, and changing the cluster quorum model. Configuring Cluster Networks After the cluster has been created, you should complete several tasks to improve cluster management. One of these tasks includes customizing the cluster networks. Each node in the cluster should have the same number of network adapters, and each adapter should Download at www.wowebook.com ptg6432687 369 Deploying a Failover Cluster for Hyper-V Hosts 12 FIGURE 12.4 Displaying the dedicated cluster storage. have already been renamed to describe a network or to easily identify which network a particular network adapter belongs to. Once the nodes are added to the failover cluster for each network card in a cluster node, there will be a corresponding cluster network. Each cluster network will be named Cluster Network 1, Cluster Network 2, and so forth for each network. Each network can be renamed and can also be configured for use by the cluster and clients, for internal cluster use only, or the network can be excluded from any cluster use. Networks and network adapters used for iSCSI communication must be excluded from cluster usage. To customize the cluster networks, complete the following steps: 1. Log on to one of the Windows Server 2008 cluster nodes with an account with administrator privileges over all nodes in the cluster. 2. Click Start, All Programs, Administrative Tools, and select Failover Cluster Management. 3. When the Failover Cluster Management console opens, if necessary type in the name of the local cluster node to connect to the cluster. 4. When the Failover Cluster Management console connects to the cluster, select and expand the cluster name. 5. Select and expand Networks in the tree pane and select Cluster Network 1 (for example). 6. In the Tasks pane, review the name of the network adapters in the network, as shown in Figure 12.5, for the iSCSI network adapters that are members of Cluster Network 1. Download at www.wowebook.com . ensure a sup- ported configuration is deployed. Download at www.wowebook.com ptg6432687 363 Deploying a Failover Cluster for Hyper-V Hosts Multipath I/O Windows Server 2008 supports multipath I/O. the high-availability “service or appli- cation” group or groups that will be deployed in the failover cluster. Each service or application group will require a separate network name and IPv4 address install the Hyper-V role on the server so that the server system is ready and configured to be a Hyper-V host server. See Chapter 4, “Installing Windows 2008 Server and the Hyper-V Role,” for