Difference between revisions of "Grid5000:UsagePolicy"

From Grid5000
Jump to: navigation, search
(Mailing Lists)
(Rules for disks reservations)
 
(22 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Maintainer|David Margery}}
+
{{Portal|User}}
 
{{Status|Approved}}
 
{{Status|Approved}}
  
= You are a Grid'5000 citizen =
+
= General principles =
 +
Grid'5000 is a scientific instrument supporting experiment-driven research in all areas of computer science, with a focus on distributed computing, cloud computing, high performance computing, big data and networking. Its use should lead to scientific results or contribute to education in this area. Other uses require a [[Grid5000:SpecialUsage|special permission from the executive committee]]. Unauthorized uses might result in prosecution. Access policy is detailed on [[Grid5000:Get_an_account|that page]].
  
== Principles ==
+
This charter defines rules to allow the shared use of this infrastructure by different communities of users, with different needs. If your intended usage does not fit within the detailed rules presented below, you can [[Grid5000:SpecialUsage|request a special permission from the executive committee]].
The Grid'5000 platform is intended to support research in all areas of computer science related to large scale distributed processing and networking.  
 
You should use Grid'5000 in the perspective of '''large scale experiments''' (at least 3 sites and 1000 CPUs).  
 
  
You may generate useful results for other communities, as long as the community of computer science researchers learns something from your experiments.
+
Exceptions are granted on a regular basis, as can be seen on [[Grid5000:SpecialUsage| the page listing those]].
  
It is a shared tool, used by many people with different and varying needs. The administrators pursue the following objectives, the main one being the first of this list:
+
= Acknowledging Grid'5000 usage =
# Make the tool available to experiments involving a significant number of nodes (in the 1000's). To make this possible, reservation fragmentation must be avoided as much as possible.
+
The sustainability of the Grid'5000 testbed is ensured through regular funding requests, for which information must be provided about usage and results obtained by experimenters.
# Keep the platform available for the development of experiments during the day. Therefore, reservations using all the nodes available on one site during work hours (in France) should be avoided in general.
+
Grid'5000 users '''must contribute to this effort by providing information about their usage upon request and in a timely manner'''. Example of such requests include highlights, 1-2-pages usage reports (for the major consumers), short slides deck about an experiment, etc.
  
== Glossary ==
+
Additionally, '''Grid'5000 must be acknowledged in all publications''' presenting results or contents obtained or derived from the usage of Grid'5000. '''All those publications must be added to the [https://hal.archives-ouvertes.fr/GRID5000 Grid'5000 collection on the HAL Open Archive].''' This can be achieved by adding your publication to HAL (possibly without the full text), and specifying "GRID5000" in the ''collaboration'' field. The '''official acknowledgment''' to use in your publication is the following:
You can use the platform with two different modes: submissions and reservations.
+
<blockquote>
* '''Submission''': you submit an experiment when you let the scheduler decide when to run it.  
+
Experiments presented in this paper were carried out using the Grid'5000
* '''Reservation''': when you make a reservation, you gain usage of the platform at the time you explicitly specified. You will then need to launch your experiment interactively.
+
testbed, supported by a scientific interest group hosted by
 +
Inria and including CNRS, RENATER and several Universities as well as
 +
other organizations (see https://www.grid5000.fr).
 +
</blockquote>
  
The different sites participating in Grid'5000 do not have clusters of the same size. Therefore, you should take into account job size when you plan an experiment.
+
= Resources reservation =
* '''Experiment''': An experiment is typically composed of one or more jobs running on Grid'5000's clusters.
+
Experiments performed on Grid'5000 typically require several resources reservations (or ''tasks'', or ''jobs'').  
* '''Job size''': the size of a job is defined by the cpu time usable by the job: (nb nodes) * (nb procs) * (job walltime). A 2 hours job using 32 bi-processor nodes has a size of 128h.
+
Resources can be reserved using three different ''queues'' (''default'', ''production'', ''besteffort''), with different usage policies described below. Unless specified otherwise, jobs are submitted in the ''default'' queue. It is possible to reserve resources ''as soon as possible'' (''submissions'', typically for small-scale reservations) or using ''advance reservations'' (for larger-scale experiments, during nights and weekends).
  
== Good usage rules (All users) ==
+
Notes:
# Please try to plan large scale experiments during night-time or week-ends.
+
* On the technical level, resources reservations are handled by the OAR resource manager. When using the command line interface, the ''queue'' is selected using the <code>-q</code> switch (e.g.: <code>oarsub -q besteffort -I</code>).
# Tuesday is the only day where you should feel authorized to use all the machines of a cluster during work hours. On the other days, please leave a few nodes for people developing or preparing an experiment. Between 09:00 and 18:00 (CEST) during the other days, you should not use more than the equivalent of 2 hours on all the processors of the cluster during a given day (e.g. on a 64 bi-processor cluster, you should not use more than 2*2*64 = 256h between 09:00 and 18:00 CEST).
+
* The usage of the testbed is actively monitored by the Grid'5000 staff. In case of usage not following the above rules, your account will be locked. [https://intranet.grid5000.fr/report_abuse/ This form] can be used to report a Grid'5000 usage that does not meet those rules and is preventing you from accessing the resources you need for your work. You can also contact the Grid'5000 staff directly (support-staff@lists.grid5000.fr).
# If you plan to use machines on a Tuesday for anything else than a large scale experiment, please wait after 13:00 (CEST) on the preceding Monday to make your reservation.  
 
# You should not have more than 2 reservations in advance, because it kills down resource usage. Please optimize and submit jobs instead.
 
# You should not be submitting jobs or making reservations if your '''experiment''' is not '''described''' in your '''[[Special:G5KReports  | User report]]'''.
 
# You must '''mention Grid'5000 in all publications''' presenting results or contents obtained or derived from the usage of Grid'5000 and you must update your '''[[Special:G5KReports  | User report]]'''. The '''official acknowledgment''' to use in your publication must be the following:
 
  
  Acknowledgment:
+
== Rules for the ''default'' queue ==
 
+
'''Daytime is dedicated to smaller-scale experiments''', and preparatory work for large-scale experiments. '''Large-scale jobs must be executed during nights or weekends''' (generally, using advance reservations). Specifically:
  Experiments presented in this paper were carried out using the
+
# Between 09:00 and 19:00 (Europe/Paris timezone) during working days (Monday to Friday, excluding public holidays in France), you should not use more than the equivalent of 2 hours on all the cores of the cluster during a given day (e.g. on a 64 bi-processor (quad core) cluster, you should not use more than (2 hours)*(2 CPU)*(4 cores)*(64 nodes)= 1024 core.hours).
  Grid'5000 experimental testbed, an initiative from the French
+
# Your jobs must not cross the 09:00 and 19:00 boundaries during week days (to extend an overnight reservation, for example). (This also means that you must not have jobs that last more than 14 hours outside weekends.)
  Ministry of Research through the ACI GRID incentive action, INRIA,
+
# You are not allowed to have more than 2 reservations in advance. ''Open Access'' users must not make ''advance reservations'' more than 24 hours in advance. (Those two rules are enforced by the resources reservation system.)
  CNRS and RENATER and other contributing partners (see https://
 
  www.grid5000.fr)
 
  
== Good usage rules (Local users) ==
+
As special exceptions, to allow additional usage of free resources during the day:
Some sites have opened user accounts on a local branch of LDAP. Users on these local branches only have access to the local cluster. In addition to the above rules, they should:
+
* Jobs of duration shorter or equal to one hour, whose submission is done less than 10 minutes before the job starts, are excluded from daily quotas.
# not have more than 1 reservation in advance;
+
** This means that one can always reserve resources for up to one hour when they are immediately available.
# prefer submissions (let oar decide when to run the job) to reservations (specifying a time when the job should run) as much as possible;
+
* Similarly, job extensions requested less than 10 minutes before the end of the job, and for a duration of one hour or less, are also excluded from daily quotas. Those extensions can be renewed several times (always during the last 10 minutes of the job).
# limit the size of their jobs to reasonable proportions such as those locally defined by the local site they have access to (e.g. in Rennes, this would be around 1280h).
+
** This means that, when resources are still available, one can always extend jobs for up to one hour.
 +
* Crossing the 19:00 boundary is allowed for jobs submitted at or after 17:00 the same day. The portion of those jobs from 17:00 to 19:00 is excluded from daily quotas.
 +
** This means that if at 17:00 or later on a given day, resources are not reserved for the following night, then it is possible to reserve them and start the ''night job'' earlier.
 +
* Crossing the 9:00 boundary is allowed for jobs submitted on the same day. But the portion of those jobs after 9:00 is still included in the daily quota.
 +
** This means that when resources are free in the morning, people are free to start working earlier.
  
== Monitoring ==
+
== Rules for the ''production'' queue ==
Platform usage is actively monitored by Grid'5000 staff. In case of unconform use, your account will be locked. Unconform use includes users whose user report is unsufficiently filled with regard to their resource usage.
+
The ''production'' queue provides access to a different and smaller set of resources (only located in the Nancy site for time being), with a policy that is more suited to long-running, non-interactive jobs. See [[Nancy:Production|this page]] for more information.
  
== Mailing Lists ==
+
Access to the ''production'' queue is '''restricted to members of organizations that are directly supporting Grid'5000'''. As of 2018-03-01, those are:
As a Grid'5000 user you are automatically subscribed to the Grid'5000 users' mailing lists. The traffic is not very high, so please keep an eye on those emails as they may contain important information (see [[Mailing lists]] for more information).
+
* members of the following laboratories: I3S (Sophia Antipolis), IRISA (Rennes), IRIT (Toulouse), LIFL (Lille), LIG (Grenoble), LIP (Lyon), LORIA (Nancy), CSC (Luxembourg)
 +
* members of the following Inria research centers: Grenoble - Rhône-Alpes, Lille - Nord Europe, Nancy - Grand Est, Rennes - Bretagne Atlantique, Sophia Antipolis - Méditerranée
 +
 
 +
A [https://hal.inria.fr/hal-01294910 document in French] explains this policy in more details.
 +
 
 +
== Rules for the ''besteffort'' queue ==
 +
The ''besteffort'' queue provides a way to submit low-priority, interruptible jobs. Access to the ''besteffort'' queue is not restricted at this point. If you are planning to use the ''besteffort'' queue for large-scale experiments, you should contact the [[Support|Grid'5000 staff]] beforehand.
 +
 
 +
== Rules for disks reservations ==
 +
Hard disk drives on nodes can be reserved in order to store datasets between nodes reservations (and avoid moving data to nodes at the beginning of each nodes reservations). See [[Disk reservation]] for more information. The maximum duration for a disk reservation is 14 days. Reservations in advance are allowed.
 +
 
 +
= Tools that can help you respect the Policy =
 +
<code>usagepolicycheck</code> is a script present on all frontends that checks whether your reservations respect the policy or not. It can be useful to launch it after you've submitted your jobs to make sure you aren't violating any rules. Here are some usage examples :
 +
 
 +
You can check current usage with
 +
  usagepolicycheck -t
 +
 +
You can discover daily allowance with
 +
  usagepolicycheck -l [--sites site1,sites2]
 +
 +
You can check your usage on a whole week (here the first week of january as an example) using:
 +
  usagepolicycheck -v --start '2019-01-01 10:00:15 +0100' --end '2019-01-15 10:00:15 +0100' on any frontends
 +
 
 +
Note that usagepolicycheck is automatically run on all frontends every week and reports usage policy violations to the offending users and Grid'5000 administrators.
 +
 
 +
= Special cases =
 +
== Special permissions ==
 +
As a reminder, if your intended usage does not fit within the detailed rules presented above, you can [[Grid5000:SpecialUsage|request a special permission from the executive committee]].
 +
Exceptions are granted on a regular basis, as can be seen on [[Grid5000:SpecialUsage| the page listing those]].
 +
 
 +
== Usage of the Internet access ==
 +
Usage of the Internet from Grid'5000 is actively monitored and logged both by the Grid'5000 staff, and by Grid'5000 upstream network provider RENATER. While Internet access is mostly unfiltered, users should contact the [[Support|Grid'5000 staff]] if their usage is likely to raise alerts (for example, experiments involving network traffic that could be considered as unauthorized usage of RENATER).
 +
 
 +
== Crypto-currency mining and other usages generating revenue ==
 +
 
 +
In the case of experiments involving crypto-currency mining or other
 +
actions that might generate revenue as a side effect, experimenters must
 +
ask the Grid'5000 staff (support-staff@lists.grid5000.fr) for
 +
credentials to use so that potential revenue is directed to an account
 +
controlled by the Grid'5000 organization.
 +
The use of Grid'5000 resources must not generate direct revenue to the user.
 +
 
 +
= Mailing lists =
 +
As a Grid'5000 user you are automatically subscribed to the Grid'5000 users' mailing lists. The traffic is not very high, so please keep an eye on those emails as they may contain important information (see [[Mailing lists]] for more information). More than 800 users are subscribed to those lists, so please be careful before asking questions on the lists.

Latest revision as of 17:05, 8 January 2019


General principles

Grid'5000 is a scientific instrument supporting experiment-driven research in all areas of computer science, with a focus on distributed computing, cloud computing, high performance computing, big data and networking. Its use should lead to scientific results or contribute to education in this area. Other uses require a special permission from the executive committee. Unauthorized uses might result in prosecution. Access policy is detailed on that page.

This charter defines rules to allow the shared use of this infrastructure by different communities of users, with different needs. If your intended usage does not fit within the detailed rules presented below, you can request a special permission from the executive committee.

Exceptions are granted on a regular basis, as can be seen on the page listing those.

Acknowledging Grid'5000 usage

The sustainability of the Grid'5000 testbed is ensured through regular funding requests, for which information must be provided about usage and results obtained by experimenters. Grid'5000 users must contribute to this effort by providing information about their usage upon request and in a timely manner. Example of such requests include highlights, 1-2-pages usage reports (for the major consumers), short slides deck about an experiment, etc.

Additionally, Grid'5000 must be acknowledged in all publications presenting results or contents obtained or derived from the usage of Grid'5000. All those publications must be added to the Grid'5000 collection on the HAL Open Archive. This can be achieved by adding your publication to HAL (possibly without the full text), and specifying "GRID5000" in the collaboration field. The official acknowledgment to use in your publication is the following:

Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER and several Universities as well as other organizations (see https://www.grid5000.fr).

Resources reservation

Experiments performed on Grid'5000 typically require several resources reservations (or tasks, or jobs). Resources can be reserved using three different queues (default, production, besteffort), with different usage policies described below. Unless specified otherwise, jobs are submitted in the default queue. It is possible to reserve resources as soon as possible (submissions, typically for small-scale reservations) or using advance reservations (for larger-scale experiments, during nights and weekends).

Notes:

  • On the technical level, resources reservations are handled by the OAR resource manager. When using the command line interface, the queue is selected using the -q switch (e.g.: oarsub -q besteffort -I).
  • The usage of the testbed is actively monitored by the Grid'5000 staff. In case of usage not following the above rules, your account will be locked. This form can be used to report a Grid'5000 usage that does not meet those rules and is preventing you from accessing the resources you need for your work. You can also contact the Grid'5000 staff directly (support-staff@lists.grid5000.fr).

Rules for the default queue

Daytime is dedicated to smaller-scale experiments, and preparatory work for large-scale experiments. Large-scale jobs must be executed during nights or weekends (generally, using advance reservations). Specifically:

  1. Between 09:00 and 19:00 (Europe/Paris timezone) during working days (Monday to Friday, excluding public holidays in France), you should not use more than the equivalent of 2 hours on all the cores of the cluster during a given day (e.g. on a 64 bi-processor (quad core) cluster, you should not use more than (2 hours)*(2 CPU)*(4 cores)*(64 nodes)= 1024 core.hours).
  2. Your jobs must not cross the 09:00 and 19:00 boundaries during week days (to extend an overnight reservation, for example). (This also means that you must not have jobs that last more than 14 hours outside weekends.)
  3. You are not allowed to have more than 2 reservations in advance. Open Access users must not make advance reservations more than 24 hours in advance. (Those two rules are enforced by the resources reservation system.)

As special exceptions, to allow additional usage of free resources during the day:

  • Jobs of duration shorter or equal to one hour, whose submission is done less than 10 minutes before the job starts, are excluded from daily quotas.
    • This means that one can always reserve resources for up to one hour when they are immediately available.
  • Similarly, job extensions requested less than 10 minutes before the end of the job, and for a duration of one hour or less, are also excluded from daily quotas. Those extensions can be renewed several times (always during the last 10 minutes of the job).
    • This means that, when resources are still available, one can always extend jobs for up to one hour.
  • Crossing the 19:00 boundary is allowed for jobs submitted at or after 17:00 the same day. The portion of those jobs from 17:00 to 19:00 is excluded from daily quotas.
    • This means that if at 17:00 or later on a given day, resources are not reserved for the following night, then it is possible to reserve them and start the night job earlier.
  • Crossing the 9:00 boundary is allowed for jobs submitted on the same day. But the portion of those jobs after 9:00 is still included in the daily quota.
    • This means that when resources are free in the morning, people are free to start working earlier.

Rules for the production queue

The production queue provides access to a different and smaller set of resources (only located in the Nancy site for time being), with a policy that is more suited to long-running, non-interactive jobs. See this page for more information.

Access to the production queue is restricted to members of organizations that are directly supporting Grid'5000. As of 2018-03-01, those are:

  • members of the following laboratories: I3S (Sophia Antipolis), IRISA (Rennes), IRIT (Toulouse), LIFL (Lille), LIG (Grenoble), LIP (Lyon), LORIA (Nancy), CSC (Luxembourg)
  • members of the following Inria research centers: Grenoble - Rhône-Alpes, Lille - Nord Europe, Nancy - Grand Est, Rennes - Bretagne Atlantique, Sophia Antipolis - Méditerranée

A document in French explains this policy in more details.

Rules for the besteffort queue

The besteffort queue provides a way to submit low-priority, interruptible jobs. Access to the besteffort queue is not restricted at this point. If you are planning to use the besteffort queue for large-scale experiments, you should contact the Grid'5000 staff beforehand.

Rules for disks reservations

Hard disk drives on nodes can be reserved in order to store datasets between nodes reservations (and avoid moving data to nodes at the beginning of each nodes reservations). See Disk reservation for more information. The maximum duration for a disk reservation is 14 days. Reservations in advance are allowed.

Tools that can help you respect the Policy

usagepolicycheck is a script present on all frontends that checks whether your reservations respect the policy or not. It can be useful to launch it after you've submitted your jobs to make sure you aren't violating any rules. Here are some usage examples :

You can check current usage with
  usagepolicycheck -t

You can discover daily allowance with
  usagepolicycheck -l [--sites site1,sites2]

You can check your usage on a whole week (here the first week of january as an example) using:
  usagepolicycheck -v --start '2019-01-01 10:00:15 +0100' --end '2019-01-15 10:00:15 +0100' on any frontends

Note that usagepolicycheck is automatically run on all frontends every week and reports usage policy violations to the offending users and Grid'5000 administrators.

Special cases

Special permissions

As a reminder, if your intended usage does not fit within the detailed rules presented above, you can request a special permission from the executive committee. Exceptions are granted on a regular basis, as can be seen on the page listing those.

Usage of the Internet access

Usage of the Internet from Grid'5000 is actively monitored and logged both by the Grid'5000 staff, and by Grid'5000 upstream network provider RENATER. While Internet access is mostly unfiltered, users should contact the Grid'5000 staff if their usage is likely to raise alerts (for example, experiments involving network traffic that could be considered as unauthorized usage of RENATER).

Crypto-currency mining and other usages generating revenue

In the case of experiments involving crypto-currency mining or other actions that might generate revenue as a side effect, experimenters must ask the Grid'5000 staff (support-staff@lists.grid5000.fr) for credentials to use so that potential revenue is directed to an account controlled by the Grid'5000 organization. The use of Grid'5000 resources must not generate direct revenue to the user.

Mailing lists

As a Grid'5000 user you are automatically subscribed to the Grid'5000 users' mailing lists. The traffic is not very high, so please keep an eye on those emails as they may contain important information (see Mailing lists for more information). More than 800 users are subscribed to those lists, so please be careful before asking questions on the lists.