HP Matrix Operating Environment Federated CMS Overview

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

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.

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.