HP Matrix Operating Environment Federated CMS Overview

HP Matrix Operating Environment Federated CMS Overview HP Matrix OE infrastructure orchestration 7.0 Technical white paper Table of contents Introduction... 2 Overview... 2 Installation and configuration... 2 Licensing... 3 Network and storage resource configuration... 3 Server provisioning... 3 Virtual server provisioning... 3 Physical server provisioning... 4 Scalability... 4 Multi-Site Support... 5 Environment configuration requirements... 6 Best practices... 6 Upgrading a single CMS to an IO federated CMS environment... 6 Primary CMS availability... 7 Server pools organization... 7 Configuring federated IO as a single homogeneous provisioning environment... 7 Configuring federated IO for separate provisioning islands... 8 For more information... 10 Call to action... 10

Introduction HP Matrix Operating Environment (Matrix OE) infrastructure orchestration (IO) is a capability delivered as part of HP CloudSystem Matrix. The IO capability provides core automation of data center infrastructure lifecycle operations and enables the creation of a self-service datacenter. IO and its supporting management software execute on a single Central Management Server (CMS). For the purposes of this document, the Matrix OE infrastructure orchestration capability is also referred to as Insight Orchestration, specifically within screen shots and product documentation. Also note that Matrix OE was formerly known as HP Insight Dynamics. An IO federated CMS environment is one where multiple management servers cooperatively share the responsibility for managing a larger number of resources than can be managed by a single server. An IO federated CMS environment allows up to four times increased scalability for service catalog-based autoprovisioning (up to 10000 virtual machines), over the current single-cms limitation of 2500 managed VMs. This paper presents a concept overview of IO federated CMS. Overview An IO federated CMS environment contains: 1 primary CMS with Matrix OE (including infrastructure orchestration) installed 1-4 secondary CMSs with Matrix OE (without infrastructure orchestration) installed CMS Quantity HP Matrix OE HP Matrix OE infrastructure orchestration Primary 1 Yes Yes Secondary 1 to 4 Yes No The primary CMS manages the aggregated resources of all CMSs. IO must be installed only on this server. A secondary CMS is a CMS that participates in the federation, where resources exist and provisioning from IO may occur, but IO does not run directly on secondary CMSs. Each CMS can be part of only one federated CMS environment at a time. Multiple federated environments cannot overlap. All CMSs in the federation must have the same version of Matrix OE installed. For example, to set up a three CMS environment, one primary CMS must be installed with Matrix OE, including IO, and two secondary CMSs must be installed with Matrix OE (without IO). IO running on the primary CMS provisions resources across multiple CMSs, utilizing the logical server management (LSM) and virtual machine management (VMM) and other supporting software layers on the secondary CMSs. Figure 1: IO federated CMS overview Installation and configuration To create a federated environment, follow this high level procedure: 2

Install the primary CMS for a Matrix OE CMS. The Matrix OE installer will enable IO federated CMS in this server and configure it as a primary CMS For each secondary CMS: o o o Install Matrix OE software without IO (this is done by de-selecting Matrix OE infrastructure orchestration functionality during install) Set up resources for management in the normal manner Add this CMS to the federation by registering it in the primary CMS. After this step, secondary CMS resources will be available to IO in the primary CMS Primary CMS for large scale requires: Separate SQL server (not installed within the CMS) o To use the same SQL server for all CMSs, different instances are required for each CMS CMS running in a physical server instead of a VM Tuning the 64-bit OS for JAVA MAXHEAP Licensing Resources must be licensed in the CMS that owns that resource. Each server resource (physical or VM host) in a secondary CMS that will be used by IO in the primary CMS must be licensed in the CMS that owns the resource with the same set of licenses required by a single environment. Network and storage resource configuration Provisioning in an IO federated environment requires careful attention to resource allocation. For example, IO uses the subnet name as the network identifier. The subnet name is defined in HP Virtual Connect Enterprise Manager (VCEM) or a VM host and detected by IO. This means that if each CMS has an underlying subnet named Sub1 in VCEM or in a VM host, this will be collapsed into one subnet. The result is that IO treats these potentially different subnets with the same name as a single network regardless of which CMS owns that subnet or if it exists in all CMSs. This behavior is important for those situations where the goal is for IO services to be deployed across multiple secondary CMSs. Therefore, ensure that networks are named identically on all CMSs of the federation if you plan to deploy a single IO service across multiple CMSs of the federation. On the other hand, this behavior does not preclude each secondary CMS from having a unique network infrastructure and SAN names so that IO templates are unique to it (meaning can only be deployed to a specific CMS). Server provisioning Server provisioning in an IO federated environment works similarly to a non-federated environment. An important characteristic enabled by federation is that an IO provisioned infrastructure service may span multiple CMSs while keeping the entire logical server group in a single CMS. For example, an infrastructure service composed of two logical server groups (LSG1 and LSG2) may have each a logical server group provisioned using resources from different CMSs. For example, LSG1 can be provisioned in CMS B and LSG2 can be provisioned in CMS C. Virtual server provisioning Each CMS in the federation must have a vcenter server registered for ESX provisioning. A vcenter server may or may not be shared by multiple CMSs in the federation. The maximum federated CMS configuration supports one vcenter server being shared across the 5 CMSs. An important characteristic of IO federated environment is that a VM template is not copied between CMSs configured with different vcenter servers. If the specified software template is available in CMS B, for example, IO will try to allocate resources from that CMS to fulfill requests. If CMS B does not have enough resources to accommodate the infrastructure service, the IO request will fail because IO will not copy software from one CMS to the other. If multiple CMSs are configured to access the same vcenter server (or those CMSs had similar software catalogs), then IO will be able to allocate virtual resources in those CMSs. 3

Physical server provisioning For physical provisioning in a federated environment, all deployment servers must be accessible from the primary CMS. If there is one deployment server serving all CMSs, the primary and secondary CMSs must have access to the deployment network used by this deployment server. If each secondary CMS has its own deployment server, they all must be registered on the primary CMS, and the primary CMS must be able to establish an https connection with those servers, and access each deployment network from each deployment server. In this case, each deployment server may offer IO jobs with the same name, and IO on the primary CMS will be able to differentiate these jobs. An important aspect when working with physical provisioning in a federated environment is related to storage pool entries (SPEs) and portability groups. SPEs specify storage resources available for a particular portability group. IO is the only component aware of the federation. The software stack on the secondary CMSs are completely unaware of the federation. Therefore, SPEs must be defined in each secondary CMS in order to specify storage resources available for the portability groups in that CMS. Portability groups do not span more than one CMS, so SPEs and portability groups cannot be shared among CMSs. For more information about portability groups, refer to the HP Insight Virtualization Manager Software with Logical Server Management User Guide at www.hp.com/go/matrixoe/docs. When IO allocates resources for a physical server, it searches for servers and SPEs in the same CMS (and portability group). IO will not allocate server and storage resources from different CMSs to assign to a physical server because there is no guarantee of connectivity among these resources in different CMSs. To choose the best SPE, IO matches storage attributes from the service template such as size, raid level and tags (not SAN fabric names nor WWN ranges). For HP rack mount servers and third-party hardware, IO uses Operations Orchestration workflows for identification and provisioning. Therefore, third-party servers can be identified and provisioned only if they are located in the primary CMS. Third-party hardware managed by the secondary CMSs will not be properly identified. Scalability With a federated environment, the supported maximum number of managed logical servers is multiplied by the number of CMSs in the federation (see figure 2). The primary CMS can manage its own resources in addition to those remote resources that are available in the federation (see figure 3). To scale to the maximum capacity of a federation, it is highly recommended that the primary CMS directly manage 1200 or fewer resources. Secondary CMSs, on the other hand, may reach their maximum capacity of 2,500 managed nodes each 1. A primary CMS can manage up to four secondary CMSs and the maximum number of managed nodes can reach 10000 nodes. Figures 2 and 3 present two architectures that would enable reaching maximum capacity for a federated environment. 1 IO federated CMS environment is intended primarily for large numbers of ESX virtual server provisioning, although Hyper-V, Integrity VM, and physical managed nodes are also supported. 4

Figure 2: IO federated CMS Scale maximum configuration 1 Figure 3: IO federated CMS Scale maximum configuration 2 Multi-Site Support Federated CMS functionality now spam multiple, geographically distributes datacenters. It provides a single console and point of control for the resources in the different datacenters. 5

Figure 4: IO Multi site federated CMS solution architecture example Environment configuration requirements A high speed, low-latency IP network connection between the primary and all secondary sites Maximum round-trip network latency of 200ms Minimum network bandwidth of 1 Gpbs Each data center must have a Matrix CMS installed and configured Each CMS instance, and its managed resources, including enclosures, physical servers and storage arrays, are colocated in the same data center vcenter server: A vcenter server must be set up for each CMS with virtual managed resources SPEs: SPEs are defined in each CMS Deployment server: limited support for physical provisioning. The primary must have access to all deployment servers in the federation which may be not allowed in a multisite environment. Best practices Upgrading a single CMS to an IO federated CMS environment A single CMS can be upgraded to become a primary CMS after installation. This is the common case when the infrastructure increasingly grows over time and nears maximum capacity of the existing Matrix Operating Environment infrastructure. When the maximum capacity is approached and the expectation is for the growth to continue, a federated environment can be planned and implemented. Ideally, when a single CMS reaches close to 2/3 of its maximum capacity (in 7.0, the maximum capacity is 2,500 managed nodes), the CMS is updated to become a primary CMS and a secondary CMS is added to the federation. Note: Once a CMS is part of a federation and has services deployed to it, that CMS cannot be broken out from the federation and managed individually. In order to remove a CMS from the federation, all services that are provisioned 6

to that CMS must first be deleted. Deleting all provisioned services to a secondary CMS is also required before that secondary CMS can be turned into a primary CMS. Primary CMS availability IO federated CMS 7.0 supports clustering a primary CMS. Server pools organization IO searches for the best resource in the environment to fulfill a service request, and does not consider in which CMS a resource is hosted. Therefore, services may span all CMSs even if there are available resources in an in-use CMS. If an administrator wants to order the allocation of CMS resources for any reason (for example, use all resources from one CMS and only after it reaches its maximum capacity, start resource allocation of anther CMS), it is a good practice to distribute resources in pools according to the CMS that owns the resources. If an administrator wants different users to use resources from different CMSs, resources can be distributes in pools according to the CMS, and access can be granted to pools. IO displays a new column called CMS in the Servers tab when IO is configured in federated mode. This allows the source CMS to be easily identified when moving resources between server pools. Configuring federated IO as a single homogeneous provisioning environment Important: this configuration is only valid for a single site environment. This is not valid for multi site setup. Depending on the setup, an infrastructure template created with IO Designer may or may not be deployable to every and all CMSs in the federation. The way that federation is configured allows for either consolidation or isolation of resources from each CMS in the federation. A single homogeneous provisioning environment is recommended, for example, to expand system scale. For a single homogenous provisioning environment, follow these recommendations: vcenter server: One vcenter server for all ESX servers under all secondary and primary CMSs (up to the recommended limits determined by VMware) Deployment server: Use one deployment server for all CMSs (for example, one RDP server shared across all CMSs sharing a single deployment network) Networks: Use the same name for networks in all ESX servers and VC domains Server pools: Can contain ESX servers from different CMSs SPEs: Define SPEs in different CMSs with equal size, raid level and tags 7

Figure 5: Single homogeneous provisioning environment Configuring federated IO for separate provisioning islands In contrast to the previous section, separate provisioning islands may be required for administration independence and isolation (see Figure 6 below). For a separate provisioning pool island in a federated environment, follow these recommendations: vcenter server: Set up a separate vcenter server for each CMS with virtual managed resources Deployment server: Set up a separate deployment server for each CMS with physical managed resources. Register all deployment servers in the primary CMS Server pools: Distribute resources across server pools according to the CMS that owns the resources. Set user access based on the rights of each user to each CMS s resources SPEs: Define SPEs in different CMSs with different tag values so they guarantee each service template is deployable to a specific CMS Service templates: Name IO templates (service templates) with a prefix that identifies the target CMS to which the template may be deployed IO template access restrictions: Enable template access restrictions and set template visibility based on the permissions each user has to the provisioning island. 8

Figure 6: Single homogeneous provisioning environment 9

For more information For more information about HP Matrix OE infrastructure orchestration, including data migration, upgrade, high availability and backing up and restoring an IO federated CMS environment, see: Backing up and restoring HP Insight Software Central Management Server (Windows) white paper at www.hp.com/go/matrixoe/docs Data migration of an existing Microsoft Windows CMS to a new Insight Software system white paper at www.hp.com/go/matrixoe/docs HP Matrix infrastructure orchestration User Guide at www.hp.com/go/matrixoe/docs HP Matrix infrastructure orchestration website at www.hp.com/go/matrixoe HP Matrix OE Information Library at www.hp.com/go/matrixoe/docs Call to action For more information about IO federated CMS and how to enable it in your environment, please contact your HP representative or visit: www.hp.com/go/matrixoe Copyright 2011-2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 5900-2259, Created June 2011; Updated February 2012, Rev. 1