behavior does not preclude each secondary CMS from having a unique network

Behavior does not preclude each secondary cms from

This preview shows page 124 - 126 out of 336 pages.

behavior does not preclude each secondary CMS from having a unique network infrastructure and SAN names so that infrastructure orchestration templates are unique to it, meaning it can only be deployed to a specific CMS. Server provisioning Server provisioning in an infrastructure orchestration federated environment works similarly to a non-federated environment. An important characteristic enabled by federation is that an infrastructure orchestration provisioned infrastructure service can span multiple CMSs while keeping the entire logical server group in a single CMS. For example, an infrastructure sen/ice composed of two logical server groups (LSG1 and LSG2) might each have 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 can be shared by multiple CMSs in the federation, or it cannot be shared. The maximum federated CMS configuration supports one vCenter sen/er being shared across the CMSs. An important characteristic of infrastructure orchestration federated environment is that a VM template is not copied between CMSs configured with different vCenter sen/ers. If the specified software template is available in CMS B, for example, infrastructure orchestration will try to allocate resources from that CMS to fulfill requests. If CMS B does not have enough resources to accommodate the infrastructure sen/ice, the infrastructure orchestration request will fail because infrastructure orchestration 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 infrastructure orchestration can allocate virtual resources in those CMSs. Rev. 14.21
Image of page 124
A Closer Look at HP Matrix Operating Environment and HP CloudSystem Matrix Physical sewer 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, 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 can offer infrastructure orchestration jobs with the same name, and infrastructure orchestration 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. Infrastructure orchestration is the only component aware of the federation. The
Image of page 125
Image of page 126

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture