Cloud Scheduler Requirements

This document contains all potential and realized requirements for the cloud scheduler that is being designed as of May 2009. Though the categories below are representative of formal requirements engineering, this document is intended to be informal. Requirements should be brief, and categorized correctly as best as possible. Also, please note whether the requirements are absolute (nonnegotiable), flexible, or potential (any ideas are appreciated).

If the categories below do not suffice, or subcategories are required, please add your own.

A note on terminology: Herein:

  • VM stands for virtual machines.
  • A "Cloud" refers to a collection of clusters running grid middleware (currently, the Globus Toolkit) as well as cloud software (currently, the Nimbus service). These clusters are connected to a job scheduler that is responsible for distributing jobs to the cloud's clusters.
  • "Cloud resources" is a more general term that refers to the clusters and individual computers that make up the cloud.
  • The "cloud environment" simply refers to configuration and status of VMs in the cloud.

Functional Requirements

(Describe the function of the intended system. What should the scheduler do?)

  • The cloud scheduler will communicate with a Condor job scheduler in order to retrieve information on queued jobs.
    • The scheduler will potentially support other job schedulers in terms of the retrieval of job information. (Abstract, job-scheduler independent interface?)
  • The scheduler will be able to obtain information on clusters (that are part of the cloud). This information may include:
    • Currently running VMs, and on what clusters the VMs are running;
    • Details of currently running VMs (OS, memory, storage, processors);
    • Details of clusters, including how much available space is available for creating new VMs;
    • Etc.
  • This cluster information may be obtained by the scheduler by any of the following methods (to be determined by further discussion and design):
    • By querying a MDS responsible for maintaining information on the cloud;
    • By internal storage of cluster information (i.e., by maintaining records of the scheduler's own instructions that have been sent to the cloud);
    • By independently querying the cloud resources and clusters for information.
  • The cloud scheduler will use information on current queued jobs and on the current cloud environment to determine the VMs that should be running in the cloud.
    • The cloud scheduler will attempt to create a cloud environment that is able to facilitate the quick and efficient completion of queued jobs.
    • Specifically, the cloud scheduler will determine how many of what type of VMs should be running at what location in the cloud.
    • The cloud scheduler will send instructions to clusters on the cloud in order to create and destroy VMs (and possibly pause VMs or move VMs to different cluster locations) in order to change the cloud environment.

Client Requirements

(Any suggested requirements from clients of the intended system. These may fit into other categories as well.)

The following requirement categories are more formal, and will only be filled in as necessary.

Performance Requirements

(Describe the performance constraints on the intended system. How fast / with how many resources should the scheduler function?)

Design Requirements

(Describe what standards the intended system should meet. How, and in accordance with what standards or guidelines, will the scheduler be built?)

-- DuncanPenfoldBrown - 01 Jun 2009

Edit | Attach | Watch | Print version | History: r7 | r4 < r3 < r2 < r1 | Backlinks | Raw View | More topic actions...
Topic revision: r2 - 2009-06-02 - dpb
  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback