cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Cluster/Host dedication logic
Date Tue, 30 Sep 2014 20:59:10 GMT
On Tue, Sep 30, 2014 at 9:39 PM, Logan Barfield <lbarfield@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message