Page tree
Skip to end of metadata
Go to start of metadata

This page describes possible use cases and examples for the Dynamic Workload Placement system. 

Scenario 1 - Keep related servers on the same node

A customer has two virtual machines - a web server and a database. They want to keep these on the same node to reduce inter-node traffic. 

To do this:

  1. Manage each virtual machine you want to keep together with related VMs. For information on how to do this, see Managing a Server.
     
  2. For each virtual machine, do the following:
    1. Click on the Keys sub-tab.
    2. Add a new placement key with the following attributes:
      1. Name = Group1.
      2. Type = Placement.
      3. Value = 1.
      4. Weight = 100.
         
The result of this setup is that the virtual machines with the Group1 placement key are attracted to one another, and should therefore start on the same node (if possible). Note that if the system calculation deems this undesirable (for instance because the node is particularly loaded), they may not always start on the same node.

Scenario 2 - Keep servers on different nodes

A customer wants to configure their web servers so that in the event of a node failure, there is minimal disruption to the services hosted on the web servers. 

To do this:

  1. Manage each virtual machine you want to keep on a different node. For information on how to do this, see Managing a Server.
     
  2. For each virtual machine, do the following:
    1. Click on the Keys sub-tab.
    2. Add a new placement key with the following attributes:
      1. Name = Repel1.
      2. Type = Placement.
      3. Value = 1.
      4. Weight = -100.
         
The result of this setup is that the virtual machines with the Repel1 placement key are repelled from one another, and should therefore start on different nodes, unless other nodes are unavailable.

Scenario 3 - Premium node service

A master billing entity has a mix of high and average specification nodes. A billing entity wants to use this to their advantage by providing a premium service to certain customers, starting virtual machines for these customers preferentially on the faster nodes when these are available. 

To do this:

  1. Manage the cluster containing both the high and average spec nodes. For information on how to do this, see Managing Clusters

    This action can only be performed by the master billing entity.

  2. Click on the Keys sub-tab.
     
  3. Add a new placement key with the following attributes:
    • Name = Premium.
    • Type = Placement.
    • Value = 0.
    • Weight = Not applicable.
       
  4. Manage each of the high specification nodes. For information on how to do this, see Managing Nodes.
     
  5. For each high spec node, do the following:
    1. Click on the Node Placement Keys sub-tab.
    2. Change the value of the Premium key to 1.
    3. Click the Update button.
       
  6. Manage the keys for the default customer. For information on how to do this, see Managing Customers.
    1. Click on the Keys sub-tab.
    2. Add a new placement key with the following attributes:
      1. Name = Premium.
      2. Type = Placement.
      3. Value = 1.
      4. Weight = -1000 (for customers who should not be able to use the faster nodes).
         
  7. Manage each customer of the billing entity that you want to be premium. For information on how to do this, see Managing Customers. For each such customer, do the following:
    1. Click on the Keys sub-tab.
    2. Add a new placement key with the following attributes:
      1. Name = Premium.
      2. Type = Placement.
      3. Value = 1.
      4. Weight = 100 (for customers to preferentially use the fast nodes)
         
The result of this setup is that when customers with Premium keys that have a weight of 100 start virtual machines, these will preferentially be on the fast nodes. When the fast nodes are unavailable, virtual machines will start on the slower node for these customers only. If a customer with a Premium key that has a weight of -1000 starts a virtual machine (the default), this will be on the slower nodes. When the slower nodes are unavailable, virtual machines for these customers should not start.
To avoid having to set keys specifically on each cluster, the premium key could be set on a customer product offer, and the customer product offer set appropriately.
  • No labels