HP Matrix Operating Environment Federated CMS Overview
7
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