Versions Compared

Old Version 35

changes.mady.by.user Sateesh Chodapuneedi

Saved on

compared with

New Version Current

changes.mady.by.user Sateesh Chodapuneedi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Author

Description

Date

Sateesh Chodapuneedi

Initial Revision

04/09/2013

Sateesh Chodapuneedi

Proposed Feature Specification

04/21/2013

Glossary

DC - VMware vCenter Data Center.
zone - CloudStack zone.
N1kv - Cisco Nexus 1000v Distributed Virtual Switch
ASA1kv - Cisco Adaptive Security Appliance 1000v
vDS - VMware vNetwork Distributed Virtual Switch.
vSwitch - VMware vNetwork Standard Virtual Switch
dvPortgroup - VMware vNetwork Distributed Virtual Portgroup
Portgroup - VMware vNetwork Standard Virtual Portgroup

...

  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.
  2. Test upgrade to new product (with this feature) when the deployment already has multiple zones, where clusters in each zone encompasses one or more of following,
    1. Single DC
    2. Multiple DCs
    3. Multiple vCenters
  3. After upgrade, test adding new cluster to existing/new zone, where the cluster belongs to a DC/vCenter that is,
    1. Already part of zone
    2. Not part of zone
  4. Test new creation of new zone

Hypervisor support

...

  1. 'cloud'.'vmware_data_center' table to track all DC specific information along with details of resources & vCenter.
    1. Columns in this table are id, uuid, DC name, guid, vCenter host, username & password. The 'guid' field encapsulates 'vCenter host/ip' and DC mor. E.g. 'vcenterDatacenter:datacenter-101@vcenter.abc.com@dc-101com'
    2. id is primary key field of this tableImplement Dao & VO for this table.
    3. Schema definition
      1. CREATE TABLE `cloud`.`vmware_data_center` (
        `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
        `uuid` varchar(255) UNIQUE,
        `name` varchar(255) NOT NULL COMMENT 'id Name of CloudStack zoneVMware datacenter',
        `guid` varchar(255) NOT NULL UNIQUE COMMENT 'id of String encapsulating VMware datacenter and vCenter',
        PRIMARY `vcenter_host` varchar(255) NOT NULL COMMENT 'vCenter host containing this VMware datacenter',
        `username` varchar(255) NOT NULL COMMENT 'Name of vCenter host user',
        `password` varchar(255) NOT NULL COMMENT 'Password of vCenter host user',
        PRIMARY KEY (`id`)
        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  2. 'cloud'.'zone_vmware_data_center_zone_map' table will be added to persist the mapping of zone to with DC.
    1. Columns in this table are id, vmware_dcdata_center_id, zone_id
    2. Foreign key id from vmware_dc tableForeign key id from data_center table
    3. Implement Dao & VO for this table.
    4. Foreign key zone_id from data_center table.
    5. Schema definition
      1. CREATE TABLE `cloud`.`zone_vmware`vmware_data_center_zone_map` (
        `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
        `zone_id` bigint unsigned NOT NULL UNIQUE COMMENT 'id of CloudStack zone',
        `vmware_data_center_id` bigint unsigned NOT NULL UNIQUE COMMENT 'id of VMware datacenter',
        PRIMARY KEY (`id`),
        CONSTRAINT `fk_zone_vmware_data_center_zone_map__vmware_data_zonecenter_id` FOREIGN KEY (`zone`vmware_data_center_id`) REFERENCES `data`vmware_data_center`(`id`) ON DELETE CASCADE,
        CONSTRAINT `fk_zone_vmware_data_center_map__vmware_data_center_id` FOREIGN KEY (`vmware_data_center_id`) REFERENCES `vmware_data_center`(`id`) ON DELETE CASCADE
        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Web Services APIs


      1. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  2. 'cloud'.'legacy_zones' table to track legacy zones in cloudstack deployment. During CloudStack upgrade, this table is populated.
    1. Columns in this table are id, zone id
      1. id is primary key field of this table
      2. Foreign key zone_id refers id from data_center table
    2. Schema definition
      1. CREATE TABLE `cloud`.`legacy_zones` (
        `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
        `zone_id` bigint unsigned NOT NULL UNIQUE COMMENT 'id of CloudStack zone',
        PRIMARY KEY (`id`),
        CONSTRAINT `fk_legacy_zones__zone_id` FOREIGN KEY (`zone_id`) REFERENCES `data_center`(`id`) ON DELETE CASCADE
        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Web Services APIs

  1. addCluster will be modified
    1. Interface perspective -
      1. No change
      2. If the zone is legacy, then hide Datacenter/DC text field in UI. Hence cluster url becomes http://vcenterhost/cluster
  2. addVmwareDc -
    1. Maps a cloudstack zone with specified VMware DC.
    2. Throws RemoteException if vCenter is not reachable or any other server side Exception caught.
    3. Upon failure in parameter validation throw InvalidParameterValueException
    4. Parameters are,
      1. zoneId - required
      2. name - required
      3. vcenter - required
      4. username - required
      5. password - required
  3. removeVmwareDc -
    1. Removes and unmaps the VMWare DC that is added to specified zone.
  4. addCluster will be modified
    1. Interface perspective - Remove parameters vCenter host/ip, username, password and DC name optional based on zone id's presence in zone_dc_map.
    2. Only required parameter is cluster name.
  5. associateZoneWithDc -
    1. Maps a cloudstack zone with specified VMware DC.
    2. Throws RemoteException if vCenter is not reachable or any other server side Exception caught.
    3. Upon failure in successful parameter validation throw InvalidParameterValueException
    4. Parameters are,
      1. zoneId - required
      2. dcName - required
      3. vCenterHost - required
      4. vCenterUser - required
      5. vCenterPassword - required
  6. disAssocaiteZoneWithDc -
    1. Unmaps a cloudstack zone from a VMWare DC that is associated with it earlier.
    2. If no association exists already, then throw CloudRuntimeException.
    3. If no such zone exists, throw InvalidParameterValueException
    4. If zone is have one or more clusters / elements, then throw ResourceInUseException - Zone should be empty (no clusters or other elements like Nexus 1000v VSM instance)
    5. Parameter are,
      1. zoneId - required
  7. listVmwareDcs -
    1. Lists VMware DCs associated with specified zone.
    2. If no association exists already, then returns empty list
    3. Parameter is,
      1. zoneId - required

UI Flow

  1. Changes required in UI
    1. Associate zone with DC
      1. Add VMware DC to zone
      2. Remove VMware DC from zone
      Dis-associate zone with DC
      2. Add Cluster form in zone wizard
      3. Add Cluster wizard
      4. Changes to support legacy zones.

    Open Issues
    Anchor
    OpenIssues
    OpenIssues

    1. Considering a model where a CloudStack deployment will have some zones with multiple DCs and some zones with single DC. This comes from the fact that existing CloudStack deployment has zones with multiple DCs. But after upgrade to the new newest version, customer would like to have existing zones to operate as-is. But all new CloudStack zones would be having single DC. In this model, the existing zone with multiple DCs is termed as Legacy zone and it will not support the zone wide features are requires a zone to have only 1 DC. Also operations on legacy zone should be seamless (like adding a cluster etc.) as they were before upgrade. This means the code base doesn't apply any new logic, that affects the functionality, over legacy zone. For example, constraint checks that happen while adding a cluster to new zone should not be done if the zone is legacy zone.

    Impact on other areas/features

    1. Impact of this feature on New features like zone wide primary storage doesn't go well with zones having multiple hypervisors. How upgrade handled for such zones?

    Impact on other areas/features

    1. Impact of this feature on zone wide primary storage support - support - vmware.
    2. Impact of this feature on storage live migration - vmware.
    3. Cisco Nexus 1000v support needs changes. 1 cluster to 1 Nexus mapping to be removed. Allow Nexus 1000v VSM instance to be associated/dis-associated with zone.
    4. Impact of this feature on ASA feature needs check.
    5. Impact of this feature on refactoring in Vmsync.

    Upgrade

    1. During CloudStack upgrade operation, 'cloud'.'legacy_zones' table is populated. This table will legacy zones in cloudstack deployment.
    2. Migration support
      1. 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 the field 'cloud'.'cluster'.'name' in database to reflect new DC name in cluster name.
        5. Edit the field 'cloud'.'cluster_details'.'url' in database to reflect new DC name in cluster name.
        6. Options to migrate VM across datacenters
          1. Cold migrate each of the instance to this new cluster in chosen DC.
          2. Hot migrate the VMs by using disconnecting all hosts from source cluster followed by deletion of source cluster from source DC and adding all hosts to cluster in target DC.
          3. Hot migrate the VMs after suspending the VMs. Need to power on (mean resume) VMs after migration is complete. This needs the virtual disks of VM to be placed on shared storage before triggering the migration operation.
      2. Pre-requisite checker tool - This tool should go through existing CloudStack deployment and VMware deployment to check if pre-requisites are met. Following are list of pre-requisites before going to upgrade to new version with this feature built-in,
        1. A CloudStack zone should encompass only 1 VMware DC
        2. The VMware DC encompassed by CloudStack zone should not be shared by multiple CloudStack deployments.
      3. deployments with clusters from multiple DCs/vCenters require consolidation of clusters into single DC.
      4. Following are options to migrate VM across datacenters
        1. Cold migrate each of the instance to this new cluster in chosen DC.
        2. Hot migrate the VMs by using disconnecting all hosts from source cluster followed by deletion of source cluster from source DC and adding all hosts to cluster in target DC.
        3. Hot migrate the VMs after suspending the VMs. Need to power on (mean resume) VMs after migration is complete. This needs the virtual disks of VM to be placed on shared storage before triggering the migration operation.
      5. Pre-requisite checker tool - This tool should go through existing CloudStack deployment and VMware deployment to check if prerequisites are met. Following are list of prerequisites would be convered during upgrade to new version of product with this feature built-in,
        1. A CloudStack zone should encompass only 1 VMware DC
        2. The VMware DC encompassed by CloudStack zone should not be shared by multiple CloudStack deployments.
    3. Guidelines of CloudStack version upgrade
      1. Migration would be offline operation before CloudStack version upgrade operation.
      2. Prerequisite checker tool would be run as part of CloudStack upgrade
      3. Choice of migration procedure is above option 1.b.(ii
      Guidelines of CloudStack version upgrade
      1. Migration would be offline operation before CloudStack version upgrade operation.
      2. Choice of migration procedure is option (2) - migration of host across DC by disconnecting from cluster in source DC, followed by connecting it to target cluster in another DC. Following are detailed steps,
        1. Handle the case of clusters from multiple vCenter
          1. Investigation pendingTo be investigated.
        2. Handle the case of clusters from single vCenter but different DCs
          1. Handle the case of deployment using distributed virtual switch (Nexus 1000v or vDS)
            1. Deploy Nexus 1000v or vDS on target DC with same credentials (user/password)
            2. Ensure if 'cloud'.'virtual_supervisor_module' table has the new IP of Nexus 1000v VSM instance.
            3. Create all dvPortgroups required by VMs on the host that is moving across DCs. Make sure all properties of dvPortGroups are in sync, e.g. shaping policy should be same as that of original dvPortGroup in source DC. External switch configuration for trunking/routes is assumed to be taken care of by admin.
          2. Decide a DC as the final DC that contains all clusters.
          3. Create a cluster, in target DC, with same properties as that of original cluster
          4. Unmanage the cluster in CloudStack
          5. Disconnect each host in source cluster
          6. Remove each host from source cluster
          7. Add each host to target cluster
          8. Create all custom properties
            1. Each VM will have custom properties like cloud.nic.mask. This will be lost during above migration operations. Hence need to re-create after adding to target cluster
            2. Each template (user VM and system VM templates) will have custom properties like cloud.uuid. This need to be restored.
          9. Add the target cluster to CloudStack
          10. Make sure that guid field of 'cloud'.'host' table has the valid reference because when host is added to target cluster, it will acquire new unique reference.
          11. Investigation pending for migration of primary/secondary datastore across DCs.
      3. Pre-requisite checker should run successfully before CloudStack upgrade operation.
      4. Run CloudStack version upgrade to complete the upgrade.

    Assumptions

    1. Sharing of resources (datastores, virtual switches like vDS, N1kv and ASA1kv etc.) with other entity (cloudstack or non-cloudstack entity) is not allowed.
    2. Cloudstack zone doesn't contain multiple hypervisors. A cloudstack zone will have only 1 hypervisor.

    Out of scope

          1. Make sure the field 'cloud'.'cluster'.'name' in database reflect new DC name in cluster name.
          2. Make sure the field 'cloud'.'cluster_details'.'url' in database reflect new DC name in cluster name.

    Assumptions

    1. Sharing of resources (datastores, virtual switches like vDS, N1kv and ASA1kv etc.) with other entity (cloudstack or non-cloudstack entity) is not allowed.
    2. Cloudstack zone doesn't contain multiple hypervisors. A cloudstack zone will have only 1 hypervisor.

    Out of scope

    1. Support zone level Cisco Nexus 1000v VSM instance.
    2. Support Zone level Cisco ASA 1000v instance.
    3. Mapping of Nexus VSM instance with zone
      1. Bring in new APIs to support associate / dis-associate a Nexus VSM instance with a zone
      2. While adding a cluster, let user choose which Nexus VSM to be used for virtual network orchestration. Actually Nexus VSM doesn't care about the cluster but it manages host. So to make the operation valid, it required (a pre-requisite) that all hosts in a cluster should be part of single Nexus VSM instance.
    4. Allow multiple Nexus VSM instances to be associated with single cloudstack zone.
    5. Architecture
      1. While adding a cluster, if N1kv instance is specified, update table cloud.virtual_supervisor_module and cloud.zone_vsm_map to assocaite N1kv VSM instance with zone
      2. Allow multiple N1kv VSM instances to be added to zone.
      3. Avoid cascaded removal of VSM instance upon cluster deletion as the association is now at zone level.
      4. Change cleanup code of N1kv VSM instances as cleanup should happen automatically with zone removal instead of cluster removal earlier.
      5. Constraint checks
        1. Only N1kv VSM of the associated DC can be added to a zone.
        2. N1kv's vCenter server connection's properties would need to be checked to retrieve the association of N1kv with a vCenter and a DC. Compare the retrieved vCenter IP and DC name with vCenter IP and DC name of current zone
    6. DB changes
      1. 'cloud'.'cluster_vsm_map' would be removed.
      2. 'cloud'.'zone_vsm_map' would be added. Also a zone can be associated with more than 1 VSM instances.
      3. Columns in this table are id, zone_id & vsm_id where id is Primary key of this table.
      4. Foreign key vsm_id from virtual_supervisor_module table.
      5. Implement Dao & VO classes for this table.
    7. Zone level Cisco ASA 1000v instance.
    8. CloudStack should be able to add/manage following DC level resources in scope of zone.
      1. Distributed virtual switches for zone wide virtual networks.
        1. Nexus 1000v DVS
        2. VMware DVS - this is already realized by zone wide traffic labels.
    9. UI Flow
      1. Support add/removal of Nexus 1000v device to a zone
      2. Support add/removal of ASA 1000v to a zone.
    10. Track relationship between resources (DC <-> DVS <> N1kv <-> ASA etc.) in cloudstack database