On Tue, Sep 30, 2014 at 9:39 PM, Logan Barfield <lbarfi...@tqhosting.com> wrote: ...
> From a service provider perspective we have two types of customers: > - Public Cloud: Using cloud instances deployed on shared > hardware/storage/etc. > - Private Cloud: Customers that pay for dedicated resources (e.g. > hypervisors, local storage, etc.) that will NOT be shared with other > customers. Private Cloud customers' instances will only be deployed on > their dedicated hardware, but will still be managed via CloudStack. > > Sticking with the CloudStack semantics of Zone = Datacenter, Pod = Rack, > Cluster = group of hosts, etc. we are trying to achieve the following goal > for Private Cloud customers. > 1) Dedicate host(s), cluster(s), or pod(s) to a domain or account. > 2) Any instance deployed by that account should be isolated to those > dedicated resources, INCLUDING the Virtual Router. > 3) No instances from any other domain/account can be deployed on the > dedicated resources of another domain/account. This includes System VMs > (Console Proxy/SSVM, Virtual Routers). > > Reasoning: A customer paying a premium for dedicated resources would not be > happy about other customers utilizing those resources. Likewise they would > not appreciate losing network connectivity because a public host (hosting > their virtual router) goes offline. With strict implicit dedication the > specified account/domain's virtual router and instances should only be > deployed on their own resources, and no other domains/accounts/virtual > routers should use those resources. The Console Proxy/SSVM instances are > fine as is: they do not current get deployed on strict implicit dedicated > hosts, and if they happen to go offline it is unlikely to critically impact > services. > I thought I recognised the use case. At Schuberg Philis we use private zones for this. I see no reason to stick to the semantics of datacenter even if that is the origin. A corner af a floor in a datacenter can be understood to be a zone as well. That said your proposed addition/alteration of the functionality below seems ok. > Even if we have to manually move the Virtual Router to the implicitly > dedicated host (since implicit dedication doesn't seem to take effect until > the first instance is deployed) it would be fine. I think the simplest > change would be to add a check in the implicit deployment planner. For > example, when deploying a service offering with Strict Implicit Dedication > for "Implicitly Dedicated Account" (pseudocode): > > Old logic: > if SystemVM exists on host > then > Fail > > New logic: > if SystemVM exists on host > then > if SystemVM Type = Virtual Router AND Virtual Router Account = > Implicitly Dedicated Account > then > Deploy VM Normally > else > Fail and throw error -> "Host not suitable for implicit > dedication because non-account System VMs exist" > I would say that the dedication should be used before that during selection of the deployment of the systemvm, the same it will be later for the vms. > > > The main failure I see to this logic is that the Virtual Router will need > to be manually moved to the implicitly dedicated host any time it is > created. Maybe a check could be added during Virtual Router deployment to > prefer implicitly dedicated resources if they exist for the account. > exactly > > Does this sound like a reasonable change to make to work around the issue > in the short term, or should a different approach be tried? > > > > > Thank You, > > Logan Barfield > Tranquil Hosting > -- Daan
