Configuration Planning Guide

Transcription

1 Configuration Planning Guide Release 6.2 Rev A July 2013

2 NOTICE The information contained in this document is subject to change without notice. UNLESS EXPRESSLY SET FORTH IN A WRITTEN AGREEMENT SIGNED BY AN AUTHORIZED REPRESENTATIVE OF STRATUS TECHNOLOGIES, STRATUS MAKES NO WARRANTY OR REPRESENTATION OF ANY KIND WITH RESPECT TO THE INFORMATION CONTAINED HEREIN, INCLUDING WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PURPOSE. Stratus Technologies assumes no responsibility or obligation of any kind for any errors contained herein or in connection with the furnishing, performance, or use of this document. Software described in Stratus documents (a) is the property of Stratus Technologies Bermuda, Ltd. or the third party, (b) is furnished only under license, and (c) may be copied or used only as expressly permitted under the terms of the license. The software described in this document is covered by the following copyright: Stratus Technologies Bermuda, Ltd. 2008, Stratus documentation describes all supported features of the user interfaces and the application programming interfaces (API) developed by Stratus. Any undocumented features of these interfaces are intended solely for use by Stratus personnel and are subject to change without warning. This document is protected by copyright. All rights are reserved. Stratus Technologies grants you limited permission to download and print a reasonable number of copies of this document (or any portions thereof), without change, for your internal use only, provided you retain all copyright notices and other restrictive legends and/or notices appearing in the copied document. Stratus, the Stratus logo, ftserver, and the ftserver logo are registered trademarks of Stratus Technologies Bermuda, Ltd. The Stratus Technologies logo, the Stratus 24 x 7 logo, ActiveService, ftscalable, Automated Uptime, and Active Upgrade are trademarks of Stratus Technologies Bermuda, Ltd. The Application Availability Experts, ComputeThru, everrun, and SplitSite are registered trademarks or trademarks of Stratus Technologies Bermuda, Ltd. Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and/or other countries; Xen and Citrix are registered trademarks and XenServer, XenCenter, and XenConvert are trademarks of Citrix Systems, Inc.; Java is a registered trademark of Sun Microsystems; Linux is a registered trademark of Linus Torvalds. Intel is a registered trademark of Intel Corporation. All other trademarks are the property of their respective owners.

3 Stratus everrun products are protected by one or more of the following patents: U.S. Patent Numbers: 5,600,784; 5,615,403; 5,787,485; 5,790,397; 5,896,523; 5,956,474; 5,983,371; 6,038,685; 6,205,565; 6,279,119; 6,473,869; 6,728,898; 7,373,545; 7,877,552. European Patent Numbers: EP ; EP ; EP ; EP ; EP ; EP ; EP ; EP ; GB ; Japanese Patent Numbers: ; ; Other patents pending. The product makes use of software covered under the GNU Public License (GPL) and the Lesser GNU Public License (LGPL). For a written copy of these licenses, see /var/ everrun/ current_everrun/licenses on any XenServer host on which everrun software is installed. Stratus will make source components available upon request, as required under the terms of the GPL. Contact everrun MX Support (US Toll-Free) or (International) Stratus Technologies Bermuda, Ltd. All rights reserved.

4 Contents Chapter 1 Introduction Overview... 1 Contents of This Guide... 1 Chapter 2 Configuration Fundamentals Overview... 3 Production Deployments... 3 FT-SMP Requirements... 4 Option A: A Local Two-Host Pool... 4 Option B: A Local Multi-Host Pool... 5 Option C: A SplitSite Two-Host Pool... 6 General Deployment Guidelines... 6 For More Information... 8 Chapter 3 Server Fundamentals Overview... 9 XenServer Hosts... 9 Where to start?... 9 How many servers?... 9 How many CPUs? What CPUs are supported? How much RAM? CPU and Server Rules System Management (Client) Computer Quorum Service Computers Summary Contents iv

5 Chapter 4 Network Fundamentals Overview...15 LAN Requirements...15 Management LAN...15 Management LAN Best Practices...16 Providing an Isolation IP Address...16 Private LANs (Availability Links)...16 Private LAN (A-Link) Rules...17 Subnet Configuration Options...17 Private LAN (A-Link) Best Practices...18 Public Production LANs...19 Public Production LAN Rules...19 Public Production LAN Best Practices...19 Additional NICs...20 Multicast Network Traffic...20 Provide TCP/IP Configurations for Production Deployment...20 Summary...20 Chapter 5 Quorum Service Fundamentals Overview...21 When is Quorum Service Required?...21 Quorum Service Rules...22 Quorum Service Best Practices...23 Summary...23 Chapter 6 Storage Fundamentals Overview...25 everrun Storage Support...25 everrun Data Protection...26 everrun Mirroring...26 Storage Subsystem Data Protection...27 Performance and Placement...29 Storage Rules...30 Summary of Storage Options...30 v Configuration Planning Guide

6 Chapter 7 Summary of Deployment Options Overview Configuration Options Meeting Your Availability Goals Protection Level 3 (System Level Fault Tolerance) Protection Level 2 (Component Level Fault Tolerance) Protection Level 1 (Basic Failover) Surviving Management LAN Segmentation Failure Best Practices to Avoid LAN Segmentation Failure Summary of Deployment Guidelines Comparison of everrun Deployment Options Appendix A Option A: Local Two-Host Pool Overview Software Servers Networking Storage PVM Deployment for FT-SMP System Connectivity Appendix B Option B: Local Multi-Host Pool Overview Software Servers Quorum Service Networking Storage System Connectivity Appendix C Option C: Two-Host SplitSite Pool Overview Software Servers Quorum Service Networking Contents vi

7 Storage...56 PVM Deployment for FT-SMP...56 System Connectivity...56 Brief Glossary everrun Terminology...59 XenServer and Industry Terminology...61 vii Configuration Planning Guide

8 Preface This document describes configuration options and best practices for the three supported classes of everrun installation: a local two-host pool; a local multi-host pool; and a SplitSite pool. Audience This guide is written for experienced technical personnel responsible for configuring, installing, administering, and managing network server hardware and software, including Microsoft Windows virtual machines. Use this guide to plan your everrun deployment. The document provides planning information to help define the configuration that will meet your availability needs. Refer to it again when you are installing everrun, to recall the configuration details and settings that will ensure a successful system deployment. This manual contains a brief glossary of key terms. After you install, you ll find an extensive glossary of terms in the everrun Online Help, which is accessible from the eac management GUI. everrun Guides The following everrun documents are shipped with this release: Read Me First is an overview of the everrun installation sequence, which explains all components and documents needed. everrun Product Overview* is a quick overview of everrun product features and functionality. everrun Release Notes* covers all known issues that affect the current release. everrun Setup and Installation Guide* provides step-by-step instructions for setting up your system. everrun Upgrade Guide* provides step-by-step instructions for upgrading to the Preface viii

9 current release. everrun Configuration Planning Guide describes configuration issues and best practices for the three supported classes of installation: a local two-host pool; a local multi-host pool; and a SplitSite pool. everrun SNMP Guide* describes everrun's implementation of the Simple Network Management Protocol (SNMP). everrun Messages Guide is a complete reference guide to the messages generated by each everrun component. everrun Evaluation Guide describes a process for testing an everrun configuration as part of a first-time setup, evaluation, or proof of concept. everrun Hardware Guide identifies the key considerations for sizing and purchasing servers to run everrun software. * These documents may be accessed (in PDF format) from the Welcome tab of the eac. The entire documentation set is also available from the everrun product download site located on the everrun Customer Portal at everrun Online Help In addition to the published guides, everrun contains an extensive online help system, with instructions for configuring and operating the everrun system. The online help contains a keyword search facility as well as an index and glossary. everrun Online Help contains detailed information about everrun system administration, including online help pages for each of the everrun (ev) command-line options. You access the Online Help from the eac Help menu. Choose Help > Contents to see a table of contents view; Help > Index for an alphabetical index of topics; or Help > Search to open a keyword search view of the Help system. The everrun Online Help is also available as a standalone Windows HTML file (in CHM format) for users who want to consult online help when the eac is not accessible. ix Configuration Planning Guide

10 Introduction 1 Overview This document provides guidelines to help plan your everrun installation and select the appropriate system, network, and storage components for your everrun configuration. These planning guidelines are meant to ensure maximum success during system installation and operation. For help in understanding the terms used in this guide, please read the everrun Product Overview and consult the brief glossary at the end of this document. Before starting your installation, review the everrun Release Notes provided with this release. To install, use both the Read Me First installation overview and the step-by-step installation details in the everrun Setup and Installation Guide. Contents of This Guide This guide describes the supported everrun deployments. Chapter 2, Configuration Fundamentals, describes the elements of an everrun system. It describes the supported production configurations: - Option A: A local, two-host pool. Minimum requirements for this option are slightly more demanding when your pool includes any protected VMs running in Level 3 SMP mode (FT-SMP operation). - Option B: A local, multi-host pool. - Option C: A SplitSite (disaster tolerant) two-host pool, where each host is located in a different room or facility, usually separated by very long distances. Appendixes A to C provide specific configuration guidelines for each of these deployments. Chapter 3, Server Fundamentals, lists XenServer host requirements. Chapter 4, Networking Fundamentals, describes the networking hardware and IP Introduction 1

11 addressing schemes needed to interconnect pool resources. Chapter 5, Quorum Service Fundamentals, discusses everrun quorum service, which runs on general-purpose computers. It provides automatic restart capabilities and data integrity assurances if specific failure modes occur. Chapter 6, Storage Fundamentals, describes storage hardware resources and configuration information. Chapter 7, Summary of Deployment Options, lists strategies for meeting your availability goals using everrun Level 3, Level 2, and Level 1 fault tolerance, as defined in the following table. The chapter describes the configuration options as mandatory or not supported, and rates them as Good, Better, or Best choices for fault tolerance or resiliency. Fault Tolerance Level Level 3, System-Level Fault Tolerance Level 2, everrun Component- Level Fault Tolerance Level 1, Basic Failover (Citrix XenServer HA) Properties Zero downtime for any failure Retention of application state and memory state during failures All the benefits of Level 2 Automated fault management policies handle server, network, and storage subsystem failures. Assured recovery of virtual machines Zero downtime due to I/O failures Zero data loss Basic failover to another host, with resource calculation to determine the number of simultaneous host failures that can be worked around Monitoring the health of hosts within a pool Shared-storage configuration required (special Citrix licensing requirements apply). 2 Configuration Planning Guide

12 Configuration Fundamentals 2 Overview This chapter describes the production deployments supported in this release. Production Deployments The production options detailed in this guide are: Option A: A Local two-host pool. This redundant two-host configuration is located in a single site, such as a computer room. It uses private, directly connected availability link (A-link) networks. Option A is the simplest to configure. It is the configuration encouraged for evaluations including tests and demonstrations of failures, recoveries, and repair scenarios. Option B: A Local multihost pool. This configuration integrates quorum services for a two, three, or four host pool. Quorum services are integrated to ensure the integrity of PVMs in the pool against multiple network failure scenarios, and to provide for unattended startup of PVMs after specific server failures have occurred. Quorum services are always recommended and required for all but the simplest of configurations (refer to Option A). Option C: A SplitSite (disaster-tolerant) two-host pool. This configuration represents the everrun SplitSite option, a disaster-tolerant deployment that maintains hardware redundancy as well as redundancy of physical computer rooms and the buildings containing them. Because of the geographic separation, the SplitSite option requires careful planning of component placement and more complex networking topologies. Quorum services are also required. FT-SMP Considerations Multi-processor VMs protected with Level 3 (System-Level Fault Tolerance or FT- SMP) provides important scalability benefits, but it also imposes additional hardware resource requirements: Configuration Fundamentals 3

13 FT-SMP operation requires Intel processors that implement the Extended Page Tables (EPT) feature. Each Level 3 PVM running in multiprocessor mode (SMP) uses 512 MB incremental RAM and CPU threads. Level 3 SMP PVMs depend on higher network performance between the XenServers. Actual demands vary with application load. If you deploy two SMP PVMs on the same pool, specify a different physical server as the primary host for each. It is possible to deploy multiple FT-SMP PVMs on the same pool, however due to application variables, configuration of more than 2 PVMs must be modeled to characterize the impact on performance. Option A: A Local Two-Host Pool An everrun protected VM (PVM) requires two physical servers, and provides redundancy by connecting a set of resources on a primary host server to a second set of resources on a different physical host, as shown in Figure 1. Figure 1 Two-host pool installed in a single computer room. 4 Configuration Planning Guide

14 This option uses two servers in a single room with directly connected Ethernet cable or fiber connections for A-Link1 and A-Link2. The first everrun (PVM) host for the protected VM resides on XenServer Host A, and the redundant everrun host is allocated from resources on XenServer Host B. The two A-links provide redundant, private connections between the two everrun hosts. Option A is recommended for evaluations and some production deployments because it is simple to configure and offers adequate insurance against common failure modes. A-Link LANs must be configured perfectly when deploying Option A. A direct-connected two-host configuration does not require you to enable quorum services. The short, point-to-point, A-link LANs minimize the likelihood of simultaneous A-link network failures, and the potential for an undesirable split-brain condition to occur. Beginning with v6.2, everrun MX configurations are no longer limited to using A-Links for quorum networking. Configuration of quorum services is highly recommended for all production deployments (refer to Option B). Option A is recommended for: Evaluations Production deployments when adequate split-brain avoidance measures can be applied Option B cannot be considered for added benefits quorum. Review the details in Appendix A for detailed requirements and recommendations if you will deploy Option A. Option B: A Local Two, Three, or Four Host Pool Use Option B (Figure 2) if you are planning to deploy a pool of two to four XenServer hosts on a single site with quorum service. Configuration Fundamentals 5

15 Figure 2 A two, three, or four host pool on one site. This deployment includes two to four XenServer hosts at the same location. To supply the required quorum service, two quorum computers are configured and placed on a LAN. The networks are typically interconnected as shown in Figure 2. Any network can be configured for use with quorum services. All quorum communications are routable. Option B is highly recommended for: Production deployments of two, three, or four XenServers in a common computer room. When redundant facilities (sites) are not feasible or not required. Review the details in Appendix B for detailed requirements and recommendations if you will deploy Option B. Option C: A SplitSite Two-Host Pool In a SplitSite deployment (shown in Figure 3 ), the two XenServer hosts are located in separate data centers or in geographically separate buildings, with wide area networking configured between them as shown in the drawing. Multiple gateways 6 Configuration Planning Guide

16 between sites A and B - and quorum computers are required (when one site fails, quorum communications with a surviving host on another site must NOT be interrupted). A common and simpler alternative to Figure 3, using direct connected A-Links (i.e. campus SplitSite with private fiber) works well. If you are not experienced with SplitSite designs, consider a professional services engagement with your service provider. SplitSite requires quorum service, configured in accordance with best practices. For best fault tolerance, a preferred quorum computer is located in a third facility and an alternate is located in a fourth. However, the alternate quorum computer can also be placed with the preferred quorum computer and still yield satisfactory results. When only two sites (or a single gateway) are available, some failures can break quorum communications with PVMs on the surviving site. Whenever a surviving PVM loses access to quorum and cannot safely complete fault handling, PVMs at the surviving site must shut themselves down and be manually restarted (a disaster recovery scenario). If Option C meets your needs, review the details in Appendix C carefully before beginning your installation and make certain you include appropriate infrastructure for the PVMs you plan to include in your deployment. Option C is best for: Production deployments when you must protect against facility falures - in addition to common equipment failures. Synchronous, automatic DR deployments when adequate A-Link networks can be provided. Review the details in Appendix C for detailed requirements and recommendations if you will deploy Option C. General Deployment Guidelines In addition to deployment topologies outlined in Appendixes A, B, and C, you can plan to protect your virtual machines at Level 3, 2, or 1, or an appropriate combination of those protection levels. If you do not plan to include XenServer HA (everrun Level 1) in your pool, some requirements associated with Level 1 can be eliminated. Specifically: You do not need to configure shared storage. When using only everrun Level 3 and Level 2, you only need to provide local storage. There is no need to consider host fencing as a result of the XenServer HA protection algorithm. You can place Level 3 and Level 2 PVMs on any host in the pool and depend on everrun fault-handling and quorum for all eventualities. Configuration Fundamentals 7

17 Figure 3 A SplitSite configuration has one XenServer host on each of two sites. The deployment shown includes active, switched A-link networks and storage attached directly to each host. You are NOT required to meet the XenServer HA requirement of a bonded NIC pair on the management network. However, it is recommended that you implement this bonded NIC to provide maximum reliability of the management network. Because a bonded NIC uses two separate network cards, this configuration consumes a minimum of four, not five NICs. 8 Configuration Planning Guide

18 The following points describe the relationship of quorum service and everrun automatic/manual master failover. If quorum service is enabled, it overrides everrun's automatic pool master failover. A VM continues to operate when the pool master fails, but the system administrator manually designates the new pool master host as required. If quorum service is disabled the everrun Management Service (MMS) provides pool master failover based on an alternative Isolation IP address capability. For More Information Networking is further described in Chapter 4, quorum service in Chapter 5, and storage in Chapter 6. When selecting a deployment option, you may find it helpful to review Chapter 7, which compares the availability provided by various deployment options and includes additional SplitSite perspectives. Appendices A, B, and C provide deployment details for software, servers, quorum service, networking, storage, and PVMs, as well as a connectivity diagram for each configuration. If you have questions that are not addressed in this guide, or if you need help to plan a custom configuration that meets your availability needs, consult your everrun MX reseller for professional deployment services. Configuration Fundamentals 9

19 10 Configuration Planning Guide

20 Server Fundamentals 3 Overview Hardware redundancy enables everrun-protected VMs to operate through failures, resulting in very high levels of availability for Windows environments. This chapter describes the basic hardware and software requirements for hosts in an everrun pool, and the general-purpose computers required for system management or quorum service management. XenServer Hosts The basic hardware requirement for a single protected VM is two separate XenServer hosts that are members of the same resource pool. Each server should be configured according to the guidelines in this chapter. Where to start? Choose two or more servers from those listed on the Citrix XenServer Hardware Compatibility List (HCL) at the link shown below. Tip: Browse to To narrow your search, specify server and enter your vendor of choice. See CPU and Server Rules on page 15 for more information. How many servers? Acquire the number of servers you will deploy to meet your capacity and redundancy requirements. See CPU and Server Rules on page 15 for more information. Server Fundamentals 11

21 How many CPUs? Populate each server with enough CPU cores/threads to meet your performance needs. The total number of CPUs required will vary greatly, according to your system design. This section lists a few factors to consider when planning your CPU requirements. See CPU and Server Rules on page 15 for more information. The XenServer environment uses four CPUs. Each running (non-protected) VM requires one or more CPUs on the XenServer host where it will run and each protected VM represents CPU requirements on two separate XenServer hosts. Each L3 PVM requires (up to) 6 extra CPU threads for an AM. Each L2 PVM requires 1 extra CPU thread for an AM. Consider the capacity requirements on each host after failover has occurred. For example, Level 2, and Level 1 PVMs may require additional resources on the machines they fail over to. - Level 3 protected VMs Always reserve the same number of CPUs on both hosts. - Level 2 protected VMs The default configuration (recommended) reserves the same number of CPUs on the active and standby hosts. It is possible to reserve a different number of CPUs on the redundant host, resulting in some disadvantages. Online migration cannot be performed (hindering software upgrade and repair scenarios) and following a failure requiring Windows to restart on the redundant host - capacity will be adjusted down/up to match the number of CPUs reserved. - Level 1 protected VMs After the VMs fail over, VM performance of all VMs will be reduced unless free CPU resources are reserved for the worst case scenario. XenServer permits a higher vcpu demand than physical CPUs that exist (over committing CPUs), however when all become active, performance can degrade significantly. For best performance, you should provide enough physical CPU threads on each server to minimize or eliminate over committing CPUs. For acceptable availability, you should provide a minimum of 1 CPU thread for each vcpu of demand on both servers. NOTE: Guidelines and a worksheet for planning your vcpu demand on a XenServer host are available in the KnowledgeBase at the everrun support website. To review these guidelines, log in to everrun Technical Support with your 12 Configuration Planning Guide

22 customer password, click the Knowledge button, and choose the Documents category in the list at left. Then type "CPU Overcommit Counters" into the Search This Category window and click Search. Server Fundamentals 13

23 What CPUs are supported? A list of the processors currently supported for everrun Level 3 SMP, Level 3 uniprocessor, and Level 2 protection is available at: If you want to evaluate whether your hardware supports everrun Level 3 multiprocessor (SMP), Level 3 uniprocessor, or Level 2 operation, download and run the everrun Compatibility Check utility to prequalify your hardware. The utility, which is available in the Tools and Utilities section of the everrun download site, checks CPU vendor, brand, and type; microcode revision; and other features required for everrun operation. It runs from a DVD or USB key attached to the target hardware and does not require XenServer or everrun software to be installed at the time. For instructions, download the Compatibility Check Readme document, also available at the everrun site in the Tools and Utilities category. How much RAM? Populate each server with sufficient RAM to support all the VMs you need to run at once. XenServer limits you to the number of VMs the physical RAM can support. Provide a minimum of 4GB of RAM per server to accommodate four (or more) protected VMs and the XenServer environment. Less RAM will constrain you to have fewer VMs or VMs with smaller amounts of memory. Tip: Make sure each of the XenServer hosts contains enough RAM to support your requirementswhen another host fails. Meeting this recommendation also provides capacity for online migration of Level 2 and Level 1 PVMs in repair or recovery scenarios. For best availability and performance, a protected VM should have identical RAM allocated on its redundant everrun host. The following guidelines apply to different PVM types. Level 3 protected VM Always requires an identical amount of RAM on both hosts. everrun is utilizing this RAM for Windows simultaneously on both physical hosts even before a failure. Each VM protected at Level 3 (uniprocessor) or Level 2 uses 128 MB of incremental RAM (beyond that configured for Windows for an AM) on both hosts. It is mandatory to meet this RAM requirement on each host. Each Level 3 PVM running in multiprocessor (SMP) mode uses 512 MB incremental RAM instead of 128 MB. 14 Configuration Planning Guide

24 Level 2 protected VM Unless configured otherwise at the time of protection, Level 2 PVMs reserve identical RAM on both hosts. RAM allocated to Level 2 PVMs depletes available resources on the host; thus Level 2 PVMs have priority over Level 1 PVMs when failover attempts are processed. In Level 2 protection the amount of RAM configured for the standby side is reserved when the PVM is started (in advance of any host failure). Online migration (a feature that permits you to maintain PVM operation during software updates or hardware repair scenarios) can be performed only if the RAM is identically configured on both hosts. However, if a PVM is configured to use less RAM on the standby host, it will still be possible to migrate with restart. Level 1 protected VM Requires identical RAM on two hosts, according to your failover needs. It is best to have ample RAM reserved when a single host failure would cause many VMs to fail over. If adequate RAM is not available, some Level 1 VMs cannot be restarted on another XenServer host. CPU and Server Rules Select a server with approved Intel processors from the lists available at everrun-support.stratus.com Minimum of 2 servers per pool; 4 maximum have been qualified. Each CPU must be the same family and model, and otherwise be eligible to join a common XenServer pool. Provide a minimum of 4 CPU cores per server; 160 CPU threads (vcpus) maximum per server. An everrun PVM may contain up to 8 vcpus. The actual number of CPUs required varies with the PVMs you plan to deploy. Refer to How many CPUs? on page 12 for guidelines. System Management (Client) Computer The client computer(s) used for everrun management can be any general-purpose computers running Windows 7, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 (all editions and versions). You use the client computer to access the two graphical management interfaces in the everrun system: The everrun Availability Center (eac) The browser-based eac everrun management GUI can be loaded and run by any Flash-enabled web browser on any computer. Server Fundamentals 15