The machine/job features mechanism

Alef, M.; Cass, Tony; Keijser, J. J.; McNab, A.; Roiser, S.; Schwickerath, U.; Sfiligoi, I.

doi:10.1088/1742-6596/898/9/092032

Cited by 2 publications

(2 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Accounting information is reported using APEL and it is encouraged that resources will be registered in GOCDB as with other CE types. Limits on available CPU time, number of processors etc are published to the VMs and jobs using the WLCG Machine/Job Features (MJF) mechanism [14].…”

Section: Designmentioning

confidence: 99%

The vacuum platform

McNab

2017

J. Phys.: Conf. Ser.

Self Cite

View full text Add to dashboard Cite

Abstract. This paper describes GridPP's Vacuum Platform for managing virtual machines (VMs), which has been used to run production workloads for WLCG and other HEP experiments. The platform provides a uniform interface between VMs and the sites they run at, whether the site is organised as an Infrastructure-as-a-Service cloud system such as OpenStack, or an Infrastructure-as-a-Client system such as Vac. The paper describes our experience in using this platform, in developing and operating VM lifecycle managers Vac and Vcycle, and in interacting with VMs provided by LHCb, ATLAS, ALICE, CMS, and the GridPP DIRAC service to run production workloads.

show abstract

Section: Designmentioning

confidence: 99%

The vacuum platform

McNab

2017

J. Phys.: Conf. Ser.

Self Cite

View full text Add to dashboard Cite

show abstract

“…It is worth noting that draining from cloud to batch requires us to define a time limit, because there is no maximum lifetime for VMs running in a CN as there is for jobs running in a WN. To address this problem, the Partition Director sets a Time To live (TTL) value as defined by the Machine/Job Features Task Force [18]. VMs can check whether a TTL is defined and stop themselves gracefully.…”

Section: Node Transitionsmentioning

confidence: 99%

Improved Cloud resource allocation: how INDIGO-DataCloud is overcoming the current limitations in Cloud schedulers

García

Zangrando

Sgaravatto

et al. 2017

J. Phys.: Conf. Ser.

View full text Add to dashboard Cite

Abstract. Performing efficient resource provisioning is a fundamental aspect for any resource provider. Local Resource Management Systems (LRMS) have been used in data centers for decades in order to obtain the best usage of the resources, providing their fair usage and partitioning for the users. In contrast, current cloud schedulers are normally based on the immediate allocation of resources on a first-come, first-served basis, meaning that a request will fail if there are no resources (e.g. OpenStack) or it will be trivially queued ordered by entry time (e.g. OpenNebula). Moreover, these scheduling strategies are based on a static partitioning of the resources, meaning that existing quotas cannot be exceeded, even if there are idle resources allocated to other projects. This is a consequence of the fact that cloud instances are not associated with a maximum execution time and leads to a situation where the resources are under-utilized. These facts have been identified by the INDIGO-DataCloud project as being too simplistic for accommodating scientific workloads in an efficient way, leading to an underutilization of the resources, a non desirable situation in scientific data centers. In this work, we will present the work done in the scheduling area during the first year of the INDIGO project and the foreseen evolutions.

show abstract

The machine/job features mechanism

Cited by 2 publications

References 3 publications

The vacuum platform

The vacuum platform

Improved Cloud resource allocation: how INDIGO-DataCloud is overcoming the current limitations in Cloud schedulers

Contact Info

Product

Resources

About