Versions Compared

Key

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

...

- we should allow multiple zone-wide primary storages

- only support for KVM with zone-wide primary storage in 4.1. Other hypervisors, like Xenserver and vmware, needs lot of extra work at the hypervisor level.A cluster can have a cluster-specific and zone wide primary storage concurrently

- There is no requirement to support multiple hypervisors (XS/VMware for example) per zone. But zone wide primary storage can operate within boundary of specific hypervisor type that supports zone wide primary storage, E.g. KVM, VMware. Hence we can have zone with multiple hypervisors and that zone can have zone wide primary storage service one particular type of hypervisor which is chosen while creating the zone wide primary storage.

- upon migration, existing customers with more than 1 cluster per zone must not have any impact – any upgrade process needs to be clearly documented

- During the upgrade, no need to allow promotion of one primary storage to become the zone-wide primary storage;

- Adding zone-wide primary to existing zone will need to be possible

-          In addition to each current primary storage

-          In lieu of current primary – in this case, storage must be migrated manually, prior to deleting the existing primary storage

- Disk offering setting will now have choices for the admin on where the disk will be created – local, cluster-wide or zone-widestorage

 - How to migrate each primary storage data to “new” zone-wide – how can this be less painful - need to be clarified

Design

In the new storage framework, each storage can have its own life cycle, the storage will be not tied to a cluster or a host. 

...

Zone, means the storage is attached to a zone, 

2. new column, called hypervisor, will be added to storage_pool table. This will be populated while creating zone wide primary storage pool.
Currently VMware and KVM are supported.

The API changes:

1. When adding a storage into cloudstack, admin needs to specify which scope he wants to add it into, either cluster or zone. Thus CreateStoragePoolCmd will have an extra parameter, called, scope.

If the scope is null, which means the scope is cluster, for api back-compatibility. 

If the scope is ZONE, hypervisor parameter would be mandatory parameter for createStoragePool. If scope is not ZONE then hypervisor parameter is optional, hence api backward compatibility is taken care.

2. A new parameter, scope, will be added into ListStoragePoolsCmd, in order to list available storages in cloudstack. 

...

1. CreateStoragePoolCmd with scope=zone & hypervisor=VMware or hypervisor=KVM

2. add storage pool into dabasedatabase

3. if there are kvm hosts in up state, send down a modifystoragepoolcmd to each kvm hosts in the zone

...

3. If there is only zone-wide storages available for a kvm host, then choose one of storage, based on first-fit algorithm

In zone wide storage pool allocator, while finding suitable pools for volume, hypervisor type of pool would be compared against hypervisor type from disk profile.