As described in experimenter introduction, ExoGENI can be thought of as both an independent collection of ‘racks’ from which the experimenter can pick the resources themselves or a single aggregate with a significant power to automatically locate and provision available resources in different racks and stitch them together. The first model is consistent with GENI-wide approach of letting the experimenter locate (‘hunt for’) resources that they need and then manually connect them together. The second approach frequently goes unnoticed by experimenters.
This post explains how to create experiment slices without being concerned as to where the resources should come from. As is common in these posts, we will be using Flukes – the ExoGENI-specific experimenter tool.
Presume we want a relatively small experiment topology (a few dozen nodes, perhaps, so we know it fits in a single rack). Finding a rack that fits those resources at any given moment may be problematic, since other experimenters are also running their experiments at the same time. So the easiest thing is to construct the slice topology and leave the locations of nodes unspecified (i.e. ‘unbound’). This will cause ExoGENI control software to attempt to identify an available rack and allocate resources for your slice to it.
Let’s start Flukes and make sure we select ExoSM as the controller we’re speaking to. When submitting requests to rack-specific controllers/SMs your slices automatically end-up in the rack of that SM.
You will be prompted for your credentials before Flukes queries the system for information. Next we can draw the topology similar to what is shown below. Notice that I used both nodes and node groups to create it.
Next step is to assign node sizes and images to each node and node group. The important note here is that we leave the ‘Select Domain’ field as System Select in all node properties dialogs (available as the right click on each node or node group). This ensures that the slice remains unbound, leaving it up to ExoGENI control software to decide where it will be placed. After we’re done with topology and image selection, we can click on ‘Auto IP’ button to automatically assign IP addresses to all the dataplane interfaces of the slice. Note that IP addresses in your slice may differ, but this is not crucial, since you can use ExoGENI script templating abilities to create the necessary customized startup scripts for your software running on the nodes.
Next we type in a unique name into the field next to ‘Submit Request’ button to create the slice. After a short delay a new window should pop up:
This is the first indication that ExoGENI was able to find the necessary resources and has begun provisioning the slice (the window may also display an error if no resources are available). This output is largely for debugging purposes, but it lists the individual reservations made for this slice (vlans and VMs) and where they are coming from. The string ‘dukevmsite.vlan’ or ‘dukevmsite.vm’ indicates the code name of the rack from which the resources are being provisioned (in this case a rack at Duke University).
We can now move to the Manifest pane of Flukes, click on ‘My Slices’ button so we can see the list of slices we created with this SM. We can select the name of this unbound slice and click ‘Query’ to get the slice manifest, which will be graphically displayed in this pane. By right-clicking on the nodes in the manifest we can learn that they have indeed been allocated from (in this case) the rack at Duke University. This is indicated in the ‘Domain’ entry in the right click menu.
Of course, if we try this experiment at different times, the output of the binding algorithm may be different, depending on which rack is more heavily used. So next time your slice may end up in a different rack. The algorithm attempts to balance the load between the racks by picking the rack that is least utilized at the time of the request submission.
Next time we will explore how to bind and stitch slices across multiple racks using ExoSM.
A note on RSpecs
Note that a similar effect can be achieved by using OMNI and GENI RSpecs, as long as your manually created RSpecs don’t use a component_manager_id attribute or specify the component manager to be “urn:publicid:IDN+exogeni.net+authority+cm”. At the time of this writing it is not clear whether or not Flack and GENI portal support this mode of operation.