"# Resources selection and environment control\n",
"\n",
"Get the resources that fit your need in terms of servers characteristics, network, disks and Operating Systems. Controlling what you get is a first step towards experiments reproducibility.\n",
" <li>⚠️ Make sure you've run the one time setup for your environment</li>\n",
" <li>⚠️ Make sure you're running this notebook under the right kernel</li>\n",
" </ul>\n",
"</div>\n"
]
},
{
"cell_type": "code",
"execution_count": null,
"id": "0ff9540e-e238-4a4c-829a-7ada3ea4cf49",
"metadata": {},
"outputs": [],
"source": [
"import enoslib as en\n",
"\n",
"# Display some general information about the library\n",
"en.check()\n",
"\n",
"# Enable rich logging\n",
"_ = en.init_logging()"
]
},
{
"cell_type": "markdown",
"id": "d8f785dd-460b-4d61-a425-af64f136cfb8",
"metadata": {},
"source": [
"## General considerations\n",
"\n",
"\n",
"Grid'5000 uses the [OAR](https://oar.imag.fr) scheduler behind the scene. The scheduler has powerful resource selections capabilities. You can refer to [some of the Grid'5000 tutorials](https://www.grid5000.fr/w/Getting_Started#Discovering,_visualizing_and_reserving_Grid'5000_resources) to explore them.\n",
"\n",
"EnOSlib exposes a higher level interface for selecting resources which is based on the [Grid'5000 REST API](https://api.grid5000.fr/) (which wraps OAR). \n",
"In EnOSlib you can reserve compute resources, networks (provided by Grid5000) and disks with the following assumptions:\n",
"\n",
"- Nodes are reserved as a whole (this makes a difference with OAR supports to reserve part of a node)\n",
"- Networks are those offered by Grid'5000 (Layer 3 subnets and Layer 2 VLANS - possibly spanning multiple sites)\n",
"- Local disks are reserved with there associated machines\n",
"\n",
"## Nodes selection\n",
"\n",
"\n",
"### By cluster name\n",
"\n",
"\n",
"In EnOSlib you can reserve some nodes by specifying the cluster name. The summary of all the available cluster is summarized in [the hardware page](https://www.grid5000.fr/w/Hardware#Clusters) of the Grid'5000 documentation.\n",
"EnOSlib supports the so called multisite experiments (experiments spanning different sites) easily. To illustrate this let's reserve nodes from different sites. The multisites experiment requires to synchronize jobs on different sites. EnOSlib eases this process for you.\n"
"On Grid’5000, machines belonging to a given cluster are normally homogeneous. But it is impossible to provide absolute guarantees about it: for instance, physical disks may have different performance characteristics across nodes of a cluster even though they share the same vendor and model. For this reason, experimenters may need to reproduce an experiment several times using the exact same hardware.\n",
"\n",
"This is possible by specifying nodes with their exact name. By default all the servers specified this way will get reserved unless you specify a target number of nodes using the nodes parameter.\n",
"\n",
"\n",
"<div class=\"alert alert-warning\">\n",
" In the following make sure to change the servers list, otherwise your reservation will conflict with others.\n",
"In all of the above we get the default network resource (the \"production network\"). This network is shared with other users.\n",
"There are two other types of networks:\n",
"- `subnets`, which can be used if you need to assign extra addresses to your nodes (e.g virtual machines)\n",
"- `kavlans` are layer 2 isolated network. Using this network type currently requires an extra step after getting the resources: **a deployement** of a full OS on the node.\n",
"\n",
"<div class=\"alert alert-warning\">\n",
" The number of kavlans is limited:\n",
" <ul>\n",
" <li>kavlan-local: 3 per sites (non routed network)</li>\n",
" <li>kavlan: 3 per sites (routed network)</li>\n",
" <li>kavlan-global: 1 per site (allow multi site, isolated experiments)</li>\n",
"# The nodes use this kavlan network for all traffic\n",
"# (the network is interconnected at layer-3 with the rest of Grid'5000)\n",
"results = en.run_command(\"ip route get 9.9.9.9\", roles=roles[\"roleA\"])\n",
"\n",
"for result in results:\n",
" print(f\"{result.stdout}\")\n"
]
},
{
"cell_type": "code",
"execution_count": null,
"id": "9b44fe33-beef-4318-aafc-f40318840c0f",
"metadata": {},
"outputs": [],
"source": [
"# release resources\n",
"provider.destroy()"
]
},
{
"cell_type": "markdown",
"id": "6b036ad6-a3ee-418d-a5aa-7a7795bbe14c",
"metadata": {},
"source": [
"## Disk reservation primer\n",
"\n",
"Grid’5000 has a [disk reservation](https://www.grid5000.fr/w/Disk_reservation) feature: on several clusters, reserving secondary disks is mandatory if you want to use them in your experiments.\n",
"\n",
"Disk reservation feature addresses different use cases:\n",
"- benchmarking of storage\n",
"- long term storage of data local to the node computing them\n",
"\n",
"Let's have a look in the following\n",
"\n",
"<div class=\"alert alert-warning\">\n",
" Make sure to specify a cluster that supports this feature -- refer to the documentation\n",
Get the resources that fit your need in terms of servers characteristics, network, disks and Operating Systems. Controlling what you get is a first step towards experiments reproducibility.
Grid'5000 uses the [OAR](https://oar.imag.fr) scheduler behind the scene. The scheduler has powerful resource selections capabilities. You can refer to [some of the Grid'5000 tutorials](https://www.grid5000.fr/w/Getting_Started#Discovering,_visualizing_and_reserving_Grid'5000_resources) to explore them.
EnOSlib exposes a higher level interface for selecting resources which is based on the [Grid'5000 REST API](https://api.grid5000.fr/)(which wraps OAR).
In EnOSlib you can reserve compute resources, networks (provided by Grid5000) and disks with the following assumptions:
- Nodes are reserved as a whole (this makes a difference with OAR supports to reserve part of a node)
- Networks are those offered by Grid'5000 (Layer 3 subnets and Layer 2 VLANS - possibly spanning multiple sites)
- Local disks are reserved with there associated machines
## Nodes selection
### By cluster name
In EnOSlib you can reserve some nodes by specifying the cluster name. The summary of all the available cluster is summarized in [the hardware page](https://www.grid5000.fr/w/Hardware#Clusters) of the Grid'5000 documentation.
EnOSlib supports the so called multisite experiments (experiments spanning different sites) easily. To illustrate this let's reserve nodes from different sites. The multisites experiment requires to synchronize jobs on different sites. EnOSlib eases this process for you.
On Grid’5000, machines belonging to a given cluster are normally homogeneous. But it is impossible to provide absolute guarantees about it: for instance, physical disks may have different performance characteristics across nodes of a cluster even though they share the same vendor and model. For this reason, experimenters may need to reproduce an experiment several times using the exact same hardware.
This is possible by specifying nodes with their exact name. By default all the servers specified this way will get reserved unless you specify a target number of nodes using the nodes parameter.
<divclass="alert alert-warning">
In the following make sure to change the servers list, otherwise your reservation will conflict with others.
In all of the above we get the default network resource (the "production network"). This network is shared with other users.
There are two other types of networks:
-`subnets`, which can be used if you need to assign extra addresses to your nodes (e.g virtual machines)
-`kavlans` are layer 2 isolated network. Using this network type currently requires an extra step after getting the resources: **a deployement** of a full OS on the node.
<divclass="alert alert-warning">
The number of kavlans is limited:
<ul>
<li>kavlan-local: 3 per sites (non routed network)</li>
<li>kavlan: 3 per sites (routed network)</li>
<li>kavlan-global: 1 per site (allow multi site, isolated experiments)</li>
Grid’5000 has a [disk reservation](https://www.grid5000.fr/w/Disk_reservation) feature: on several clusters, reserving secondary disks is mandatory if you want to use them in your experiments.
Disk reservation feature addresses different use cases:
- benchmarking of storage
- long term storage of data local to the node computing them
Let's have a look in the following
<divclass="alert alert-warning">
Make sure to specify a cluster that supports this feature -- refer to the documentation
