HP Matrix Operating Environment Federated CMS Overview

3
 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 Install Matrix OE software without IO (this is done by de-selecting Matrix OE infrastructure
orchestration functionality during install)
o Set up resources for management in the normal manner
o 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.