Daan/Saksham,
I would like to hash out exactly what problem needs to be solved before
opening a Jira ticket about it.
Daan, to answer your question I haven't implemented anything yet. I'm not
a programmer, so at best I can come up with half-baked patches. To answer
your other question regarding the use case, let me try to clarify a bit.
>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.
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"
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.
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
On Tue, Sep 30, 2014 at 5:24 AM, Saksham Srivastava <
saksham.srivast...@citrix.com> wrote:
> Logan you are correct. We currently have a limitation on placing system
> vms and VRs on dedicated resources. They do not strictly adhere to
> dedication.
> It would be good if you could please file Jira tickets regarding the
> proposed enhancements so that we can track it.
>
> Thanks,
> Saksham
>
> -----Original Message-----
> From: Logan Barfield [mailto:lbarfi...@tqhosting.com]
> Sent: Monday, September 29, 2014 11:35 PM
> To: dev@cloudstack.apache.org
> Subject: Cluster/Host dedication logic
>
> I was doing some testing with the explicit and implicit dedication
> features, and was just wondering about the logic behind it.
>
> From a service provider perspective this feature seems most useful for
> dedicating certain resources to a domain or account. In other words, a
> client pays for a single host/cluster of hosts, and all their instances are
> isolated on those hosts.
>
> Right now if a host/cluster is explicitly dedicated system VMs will ignore
> that dedication and deploy on the dedicated hosts anyway. This isn't ideal
> because the system VMs consume resources dedicated (and being paid for) by
> a single client. That being said the system VMs have to get deployed
> somewhere, so this is probably the best solution overall.
>
> To get around this issue a host can be implicitly dedicated. In this case
> only VMs specifically deployed by the dedicated user will be provisioned on
> their resources. This prevents unwanted resource consumption on the
> dedicated infrastructure. However, this causes the opposite problem with
> virtual routers. The dedicated client's virtual router is deployed on
> shared resources, instead of their dedicated infrastructure. This isn't
> ideal, because a customer paying for dedicated resources can be negatively
> impacted by an issue with the shared hosts (e.g., host running their VR
> goes down causing network outages).
>
> Would it be hard to change the implicit dedication logic to allow the
> virtual router owned by an account to reside on their implicitly dedicated
> resources, or even to prefer those resources? This would ensure that a
> client paying for dedicated resources would only be affected by outages on
> their own hardware. If a console proxy or secondary storage VM goes down
> they would still be affected, but that's a much less urgent/immediately
> visible problem than losing a virtual router.
>
> I know the implicit dedication manager views virtual routers as being
> owned by the "system" right now, but since they are tied to a specific
> account I don't think this change would be too hard to implement.
>
> Is my logic sound on this, or is there something I'm not considering?
>
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>
