Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Sharednodes

Sharednodes

Shared Multiplexed Nodes in Emulab

Shared Multiplexed Nodes in Emulab

Overview

Emulab now supports the use of shared physical nodes via multiplexed virtual nodes. Typically, physical nodes in Emulab are dedicated to a single experiment; users dedicate the entire node, or can build multiple virtual nodes on them. Either way, no other project or experiment has access to that node. This ensures that users get total control of their experimental setup.

The downside of dedicated physical nodes is that most users do not fully utilize their nodes. This is a waste of scarce resources.

Emulab has addressed this problem by allowing nodes to be operated in shared mode. When a node is in shared mode, multiple experiments can be using that node at the same time. Emulab's multiplexed virtual nodes allow complete separation so that privacy is maintained. Unlike dedicated nodes, users do not get accounts on the physical host, but only inside the virtual node containers. From almost all perspectives, the experimenter is not aware that other experiments are running on that physical host.

Important: Use of shared nodes is voluntary and explicit: you'll only get placed on a shared node if you specifically request it. If you don't change your NS file, you will continue to get dedicated physical machines in Emulab.

Use

Using shared nodes is very simple since it uses the same NS file format as dedicated Emulab OpenVZ multiplexed virtual nodes, with some small additions:

	tb-set-node-usesharednode $nodeA 0.9
	tb-set-node-os $nodeA OPENVZ-STD

or Emulab XEN nodes:

	tb-set-node-usesharednode $nodeA 0.9
	tb-set-node-os $nodeA XEN-STD

The first statement specifies your willingness to place nodeA on a shared node. Like all Emulab desires, it is represented as a number between 0.0 and 1.0, where 1.0 would indicate you will only accept a shared node (probably not much point in doing this). When Emulab maps the experiment, it will do its best to place any nodes you have specified as accepting a shared node, on a shared node. At the moment though, the actual weight is ignored, and if shared nodes are available they will be used. Otherwise, Emulab will fall back to its default mode of using dedicated nodes.

The second statement indicates the OS you want. To get the most uptodate Emulab default, you can specify OPENVZ-STD or XEN-STD, which maps to OpenVZ or XEN container-based virtualization. You may also specify a custom OS derived from a standard container image.

Shared Pool

To make sure that shared nodes are readily available, Emulab maintains a pool of nodes that are in shared mode. The pool is automatically adjusted according to demand; as nodes fill up with containers, more nodes will be added to the pool. When a node no longer has any containers on it, it is released from the pool and into the general node population. The current pool can be viewed in the web interface.

Resource Controls

At the moment, there are no resource controls on containers. While we do limit the number of containers on a physical node, there is nothing to prevent individual containers from consuming more then their fair share of resources. A future project is to implement resource controls using OpenVZ resource management.