Page History

...

- we should allow multiple zone-wide primary storages

-  if user unmounts the disk on a shared store and remounts on a VM which happens to be on a cluster that does NOT have shared zone-wide primary store (or vice-versa), CS still have to make this disk available on the new target VM (do double copy as is done today?)

Open questions

- ideally, instead of making the NFS share be available as a primary storage for all clusters (unless explicitly excluded by a cluster), would it be better if we simply allow more than one cluster to specify the same NFS share as a primary storage (latter is preferable)

- what would be the migration issues/requirements - for example, do we allow an existing NFS share that is a primary storage already to be "upgraded" to a zone-wide primary storage? 

- is there any impact of doing maintenance of this nfs? Or removing the primary share for a cluster?

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.

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. 

The DB changes:

1. new column, called scope, will be added into storage_pool table. The scope has following attributes:

    HOST, CLUSTER, ZONE;

Host means the storage is attached to a particular hypervisor host, a.k.a, it's the local storage.

Cluster, means the storage is attached to a cluster, it's the primary storage we have today.

Zone, means the storage is attached to a zone, 

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. 

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

If the scope is null, which means list storage pool whose scope attribute is cluster, for api back-compatibility.

The flow of how to register a zone-wide primary storage:

1. CreateStoragePoolCmd with scope=zone

2. add storage pool into dabase

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

4. Then finished

5. Whenever a new kvm hosts added into the zone, also send down modifystoragepoolcmd to the host.

The change in storage allocator:

If there are zone-wide storages available in the zone, storage allocator will use the following algorithm:

1. Only use zone-wide storage, if it's for kvm hypervisor

2. If there are both cluster/host wide storages available for a kvm host, choose cluster or host wide storage at first.

3. If there is only zone-wide storages available for a kvm host, then choose one of storage, based on first-fit algorithm- what is the performance/scalability limitation?