Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated introduction section

...

In today's implementation, vSphere DC is invisible to CloudStack, we allow multiple clusters (vSphere DC) even from different vCenter instances to be added to CloudStack zone. Issues:-
1) This implies following,

  1. Multiple vCenter instances in same cloudstack zone.

...

  1. Multiple

...

  1. DCs in same cloudstack zone.

...

  1. 1:1 mapping of

...

  1. N1kv VSM instance with cluster
  2. 1:1 mapping of

...

  1. ASA instance with cluster

...

  1. 1:1 mapping of

...

  1. cluster to vmware DC is recommended to support multiple cloudstack deployments in same DC.
  2. vDS - zone wide traffic label

...

  1. override is required in case of a zone with multiple DCs.
  2. A primary storage of the scope zone is not inherently possible because datastore is an object scoped at DC, if a zone contains more than 1 DC this is not supported.
  3. Live migration of VM across clusters in a zone is not inherently possible if 2 clusters are in different DC's.

To address these issues, let Cloudstack should explicitly manage vSphere DCs. Treat CloudStack zone as capacity-planning and operating unit, in case of deployment with multiple DCs use multiple CloudStack zones configured per DC and share the same network infrastructure, they only need to carefully allocate IPs/VLANs etc. to multiple CloudStack zones to make it happen.

Purpose

This document describes the specifications and design of new data model for cloudstack zone for VMware environment.

References

1 http://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration-maximums.pdf
2 http://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configuration-maximums.pdf
3 http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

...

With this feature, Vmware datacenter will be put under management of CloudStack zone.
In previous releases, Vmware datacenter is hidden behind a CloudStack cluster, we need an explicit mapping policy for Vmware datacenter both
for zone-wide storage and zone-wide network resources. This makes datastore in a DC to span across clusters scoped by cloudstack zone. Also this means dvSwitch in DC spans across clusters in the zone. VM live migration across clusters in zone can be realized with this model.

1:1 relationship between vSphere DC to CloudStack zone is a natural mapping from resource point of view, whether it's storage (datastore) or network (distributed switches etc.). Within the zone/DC, it's possible to have multiple vSphere clusters (within the same DC). And this will have the implication that CloudStack zone size (how many hosts within a zone) will be limited to what vSphere allows. See 1, 2 & 3 in References section.

Test Guidelines

  1. All VMware test cases need to be covered, as new mapping of DC to CloudStack zone is a change in critical path of VMware hypervisor plugin.

...

In this explicit model, CloudStack will understand the relationship between a Vmware datacenter and resources underneath it, so when resources like a Vmware cluster or dvSwitch that is added to CloudStack, the underlying Vmware resource relationship between these objects will become constraint information
for CloudStack to use.
For example, a Vmware cluster can't be added to a CloudStack zone if it's Vmware DC is not under the CloudStack zone, also an ASA instance cannot be added to a Vmware cluster that its Vmware DC is not in the zone.

...

  1. Single DC will NOT be allowed to be managed by multiple cloudstack deployments. Name space collision issues within DC will be resolved by this.
  2. Nexus support needs changes. 1 cluster to 1 Nexus mapping to be removed. Allow Nexus 1000v VSM instance to be added to zone/DC.
  3. Impact of (1) on ASA feature needs check.
  4. Impact of this feature on refactoring in Vmsync.

Upgrade

  1. Migration support
    1. Old customers Existing CloudStack Deployments - Existing cloudstack deployments with multiple DC's in a zone
      1. Decide a DC as the final DC that contains all clusters.
      2. Move all clusters to the chosen DC.
      3. For each cluster create cluster with same name in target DC.
      4. Edit dc name to match that of chosen DC where ever the dc name is present (Ex: 'guid' field in hosts table)
      5. Cold migrate each of the instance to this new cluster in chosen DC.
    2. New customers Fresh CloudStack Deployments - Existing VMware deployments with clusters to be managed by cloudstack spread in multiple DC's
      1. Move all clusters meant for single zone into 1 DC
      2. For each cluster create cluster with same name in target DC.
      3. Put each host, in that cluster, in maintenance mode
      4. Remove each host in maintenance mode from the cluster
      5. Add each host to new cluster in target DC
        1. Get the host out of maintenance mode