## 1.1 Purpose

The purpose of this Software Requirements Specification (SRS) is to describe the requirements and specifications of Libra, an Economy-Driven Cluster Scheduler. This document outlines the functional features of the scheduler, including interface details, design constraints, and performance characteristics. The SRS is intended for users and owners of high-performance clusters, cluster management software, job schedulers, and grid resources. Libra aims to provide a market-based, economy-driven service for managing batch jobs on clusters by scheduling CPU time according to user utility rather than system performance considerations, thereby offering Quality of Service (QoS) computational economy in cluster computing.

## 1.2 Scope

The software product to be produced is the Libra Scheduler, an add-on to the Sun Grid Engine (SGE) cluster management system. The Libra Scheduler is designed to manage batch jobs on clusters by scheduling CPU time based on user utility rather than system performance considerations. Its primary function is to provide a market-based, economy-driven service that optimizes Quality of Service (QoS) in cluster computing.

The application of the Libra Scheduler is specifically for managing sequential and embarrassingly parallel batch jobs on a homogeneous Linux cluster. The scheduler aims to maximize user satisfaction by considering user-specified constraints such as budget and deadline, rather than traditional system-centric policies. This approach allows for dynamic resource allocation, ensuring that users who prioritize urgency and are willing to pay a premium can have their jobs completed promptly.

The main objective of the Libra Scheduler is to implement a computational economy in cluster computing, enhancing the efficiency and effectiveness of resource management. While the current scope is limited to CPU time scheduling on homogeneous clusters, the functionality can be adapted for other resources and heterogeneous clusters in the future. The scheduler does not provide mechanisms for user interaction or bargaining over resources, distinguishing it from grid-computing environments like Nimrod/G.

### 1.3.1 Product perspective

The Libra Scheduler is an add-on to the Sun Grid Engine (SGE) cluster management system, which operates on a Linux-based cluster. It is designed to enhance the queuing, scheduling, and resource management capabilities of SGE by introducing a market-based economy-driven service for managing batch jobs on clusters. The primary objective of Libra is to provide Quality of Service (QoS) computational economy in cluster computing.

#### System interfaces
Libra interfaces with the Sun Grid Engine, which is responsible for receiving job submissions and delegating them to Libra for scheduling. Libra then communicates its scheduling decisions back to the resource manager, which dispatches the jobs to the appropriate workstations. No modifications to the Linux kernel are required.

#### User interfaces
Libra provides interfaces for two types of users: cluster users and cluster administrators. Users can interact with the system through the Linux command prompt or the SGE interface to submit jobs, monitor job status, and manage job submissions. Administrators have additional capabilities to oversee cluster operations and modify scheduling policies.

#### Hardware interfaces
Libra utilizes the hardware interfaces provided by the Sun Grid Engine, including CPU usage, memory usage, swap file creation, and network communication. It operates on a network of workstations running the Linux operating system.

#### Software interfaces
Libra interfaces directly with the modified Sun Grid Engine cluster management system, version 5.3. It also utilizes the PVM (Parallel Virtual Machine) and MPI (Message Passing Interface) libraries for executing embarrassingly parallel jobs. The operating system is Linux, and all coding is done in standard C.

#### Communications interfaces
Libra uses the communications architecture of the Sun Grid Engine and does not have unique communications interfaces beyond those provided by SGE.

#### Memory constraints
[N/A]

#### Operations
Libra supports both user-initiated and administrator-initiated operations. Users can submit jobs, monitor their status, and manage job parameters. Administrators can oversee the entire cluster, modify scheduling policies, and manage job execution.

#### Site adaptation requirements
[N/A]

#### Interfaces with services
[N/A]

### 1.3.2 Product functions

The Libra Scheduler is designed to enhance the Sun Grid Engine cluster management system by providing a market-based, economy-driven service for managing batch jobs on clusters. The major functions of the Libra Scheduler include:

- **Job Submission and Initialization**: Users can submit jobs with specific parameters such as budget, deadline, and execution time. The scheduler initializes these jobs by setting variables that represent the state of the cluster and its queues.

- **Job Scheduling and Resource Allocation**: The scheduler uses a bid-based proportional resource-sharing model to allocate CPU time to jobs based on user-defined priorities, such as budget and deadline. The Stride Scheduling Algorithm is employed to ensure resource allocations are proportional to these priorities.

- **Dynamic Resource Management**: The scheduler dynamically reallocates resources to accommodate urgent jobs, allowing users to pay a premium for expedited processing. This includes changing resource limits, priorities, and execution order of jobs.

- **Job Monitoring and Management**: Users and administrators can view job status, and under certain conditions, modify job parameters. The system provides options to delete or change jobs, ensuring flexibility in job management.

- **Execution Host Determination and Job Dispatching**: The scheduler determines the most suitable execution host and queue for each job, considering factors like load balancing and job type. Jobs are dispatched to the selected host and queue for execution.

- **Cluster Status Updates**: The scheduler continuously updates the cluster status, reflecting changes in resource allocation and job execution, ensuring accurate and up-to-date information for decision-making.

- **Administrative Functions**: Administrators have additional capabilities to oversee the entire cluster, including altering cost structures, scheduling policies, and managing job execution.

These functions collectively aim to maximize user utility by optimizing resource utilization within user-imposed constraints, ensuring a high level of Quality of Service (QoS) in cluster computing environments.

### 1.3.3 User characteristics

The Libra Scheduler is designed for two primary user groups: cluster users and cluster administrators. 

- **Cluster Users**: These users are responsible for submitting jobs to the cluster. They must have a clear understanding of the job's nature, including execution time and required resources. Technical expertise is necessary to effectively use the interface for job submission.

- **Cluster Administrators**: Administrators oversee scheduling and cluster usage. They must be advanced cluster operators with comprehensive knowledge of Linux, the Sun Grid Engine (SGE), and the Libra Scheduler. Their role involves managing the cluster's operational aspects and ensuring efficient resource allocation.

Both user groups require a certain level of technical proficiency to interact with the system, which may influence usability.

### 1.3.4 Limitations

a) Regulatory requirements and policies: [N/A]

b) Hardware limitations: The current hardware setup consists of a network of four Pentium-III workstations with 128 MB RAM each, which may limit performance analysis. A larger number of dedicated workstations would be beneficial for better performance analysis.

c) Interfaces to other applications: Libra will interface with the Sun Grid Engine (SGE) cluster management system and utilize its interfaces for CPU usage, memory usage, swap file creation, and network communication.

d) Parallel operation: Libra will support the execution of embarrassingly parallel jobs using PVM (Parallel Virtual Machine) and MPI (Message Passing Interface) libraries.

e) Audit functions: [N/A]

f) Control functions: Libra will provide administrative security to ensure full control over job execution and prevent unauthorized alteration of scheduling criteria or resource allocation.

g) Higher-order language requirements: All coding will be done in standard C.

h) Signal handshake protocols: [N/A]

i) Quality requirements: The maximum bug rate is set at 1 bug/KLOC, and the maximum time to repair in case of system outage is less than five minutes.

j) Criticality of the application: [N/A]

k) Safety and security considerations: Libra will ensure the privacy of user job status and control over job execution, with administrative authority required for any alterations.

l) Physical/mental considerations: [N/A]

m) Limitations from other systems: The workability of the Sun Grid Engine cluster management system modules, such as those dealing with process migration, is assumed to be compatible with the scheduling policies provided by the Libra Scheduler.

## 1.4 Definitions

- **Cluster/Cluster Computing**: Connecting two or more computers to leverage combined computational power and resources, providing a single system image across all nodes. Used for high-performance applications like AI, nuclear simulations, and scientific calculations.

- **QoS (Quality of Service)**: Meeting user requirements to maximize their utility.

- **Computational Economy**: Incorporating user-specified QoS parameters with jobs, focusing on a user-centric approach for resource management, prioritizing user constraints like deadlines and budgets over system-centric policies.

- **Linux**: An open-source operating system with extensive documentation and user support.

- **Grid Computing**: An infrastructure that integrates resources like computers, software, and devices across the Internet, presenting them as a unified resource for processing jobs.

- **Bid-based Proportional Resource-Sharing Model**: An economic model for allocating cluster resources based on user criteria like deadlines and budgets, where resource allocation is proportional to user bids.

- **Stride Scheduling**: A scheduling algorithm that allocates resources proportional to a user's priority or share, using a pool of tickets representing resource rights.

- **Process Migration**: Moving a job from one computer system to another without restarting it.

- **Sequential Jobs**: Jobs that must run on a single node and cannot be split into separate jobs.

- **Embarrassingly Parallel Jobs**: Parallel jobs with independent parts that can be split and performed on separate nodes with minimal inter-job communication.

- **Job Accounting**: Quantifying the system resources used by a job.

- **GUI (Graphical User Interface)**: A user interface that includes graphical elements.

- **CPU (Central Processing Unit)**: The primary component of a computer that performs most of the processing.

- **SGE (Sun Grid Engine)**: A cluster management system.

- **Open-source software**: Software with freely available code for use and research.

- **Homogenous cluster**: A cluster where nodes have uniform characteristics, such as memory size and operating system.

# 2 References

## Compliance

1. R. Buyya, D. Abramson, and J. Giddy, "Nimrod/G: An Architecture for a Resource Management and Scheduling System in a Global Computational Grid," HPC ASIA’2000, China, IEEE CS Press, USA, 2000.

2. R. Buyya, D. Abramson, J. Giddy, "An Economy Driven Resource Management Architecture for Global Computational Power Grids," The 2000 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA 2000), Las Vegas, USA, June 26-29, 2000.

3. R. Buyya, D. Abramson, and J. Giddy, "An Economy Grid Architecture for Service-Oriented Grid Computing," 10th IEEE International Heterogeneous Computing Workshop (HCW 2001), with IPDPS 2001, SF, California, USA, April 2001.

4. Rajkumar Buyya, Heinz Stockinger, Jonathan Giddy, and David Abramson, "Economic Models for Management of Resources in Peer-to-Peer and Grid Computing," Monash University.

5. B.N. Chun and D.E. Culler, "Market-based proportional resource sharing for clusters," Submitted for publication, September 1999.

## Guidance

[N/A]

## 3.1 Functions

The Libra Scheduler is designed to manage batch jobs on clusters by scheduling CPU time according to user utility. The following functions outline the fundamental actions required for accepting and processing inputs, as well as generating outputs:

### 3.1.1 Submit Job
- **Inputs**: User information, job information, and cluster information.
- **Processing**: Validates if the cluster is open for job submissions and verifies user credentials.
- **Outputs**: Boolean values indicating submission acceptance and user verification.

### 3.1.2 View Job Status
- **Inputs**: User ID and password.
- **Processing**: Displays job details and execution progress.
- **Outputs**: User view of job status options.

### 3.1.3 Delete/Change Job
- **Inputs**: User ID and password.
- **Processing**: Removes or updates job parameters, revises scheduling decisions.
- **Outputs**: Updated cluster information and scheduling decisions.

### 3.1.4 Initialize Job
- **Inputs**: Job details and job ID from SGE.
- **Processing**: Retrieves job details and sets cluster state variables.
- **Outputs**: Job details including job ID, type, execution time, and constraints.

### 3.1.5 Accept/Reject Job
- **Inputs**: Job details and cluster information.
- **Processing**: Determines job priority and feasibility based on budget and deadline.
- **Outputs**: Boolean acceptance status and suggested conditions for acceptance.

### 3.1.6 Calculate Scheduling Information
- **Inputs**: Job details.
- **Processing**: Allocates tickets, calculates stride and pass for scheduling.
- **Outputs**: Scheduling information including tickets, stride, and pass.

### 3.1.7 Determine Execution Host
- **Inputs**: Job details and cluster information.
- **Processing**: Selects least loaded host and appropriate queue for job execution.
- **Outputs**: Chosen execution host and queue.

### 3.1.8 Dispatch Job
- **Inputs**: Execution host and queue.
- **Processing**: Inserts job into the queue for execution.
- **Outputs**: Scheduled job in its designated host and queue.

### 3.1.9 Update Cluster Status
- **Inputs**: Job details and execution host.
- **Processing**: Reserves resources, updates queue status, and informs the master host.
- **Outputs**: [N/A]

### 3.1.10 Execute Job
- **Inputs**: Scheduled job details and scheduling information.
- **Processing**: Allocates CPU time based on stride-scheduling algorithm.
- **Outputs**: Updated cluster information including CPU load and node status.

### Validity Checks and Error Handling
- **Validity Checks**: Ensure user authentication and job parameter correctness.
- **Error Handling**: [N/A]
- **Responses to Abnormal Situations**: [N/A]

### Effect of Parameters
- **Parameters**: Budget and deadline significantly influence job scheduling and priority.

### Relationship of Outputs to Inputs
- **Input/Output Sequences**: Job submission leads to scheduling and execution.
- **Formulas for Input to Output Conversion**: [N/A]

## 3.2 Performance requirements

### 3.2.1 Response time
The maximum response time for the submission of a job will be 1 minute.

### 3.2.2 Capacity
The maximum number of jobs schedulable is limited only by the capacity of the nodes to fulfill the jobs’ deadlines; there is no upper limit inherent in the Libra scheduler as such.

### 3.2.3 Deadline sensitivity
Assuming submitted statistics for jobs are accurate, the Libra scheduler will ensure that all jobs are completed with a 10% error allowance.

### 3.2.4 Cost sensitivity
Under all circumstances, the maximum cost payable as submitted by the user will be the maximum cost charged to the user.

## 3.3 Usability requirements

The usability requirements for the Libra Scheduler focus on ensuring that both users and administrators can effectively and efficiently interact with the system, achieving their objectives with satisfaction and minimal risk of error.

- **Effectiveness**: The system should allow users to submit jobs, monitor their status, and manage job parameters with ease. Administrators should be able to oversee scheduling, manage cluster resources, and alter scheduling policies without difficulty.

- **Efficiency**: The interface should facilitate quick job submission and management, minimizing the time required for users to perform tasks. The system should provide rapid feedback, with a maximum response time for job submission set at 1 minute.

- **Satisfaction**: Users and administrators should find the system intuitive and straightforward, with clear commands and options available through the Linux command prompt or the Sun Grid Engine interface. A potential future GUI should enhance user satisfaction by providing a more accessible and visually appealing interface.

- **Avoidance of Harm**: The system should ensure the privacy of user job status and prevent unauthorized alterations to scheduling criteria or resource allocations. This is crucial to maintaining trust and preventing misuse of the system.

These usability requirements aim to ensure that the Libra Scheduler is user-friendly, efficient, and secure, providing a positive experience for all users involved. [N/A]

## 3.5 Logical database requirements

[N/A]

## 3.6 Design constraints

The design of the Libra Scheduler is subject to several constraints:

- **Parent Component**: The Libra scheduler will be a sub-component of the Sun Grid Engine (SGE), which imposes certain integration and compatibility requirements.

- **Software Language**: All coding for the Libra Scheduler will be done in standard C, adhering to the language's constraints and capabilities.

- **Scheduling Constraints**: The scheduler will not perform exhaustive searches of all possible job combinations. Instead, heuristics will be developed to address the scheduling problem efficiently.

- **Licensing**: The Libra Scheduler will be released under the GNU General Public License (GPL), which imposes constraints on how the software can be used, modified, and distributed.

- **Open Source Requirements**: As an open-source project, all documentation and code must comply with the requirements of open-source software under the GNU General Public License, including the provision of man pages for online user documentation.

- **Hardware Interfaces**: Libra will utilize the hardware interfaces provided by the Sun Grid Engine, which include CPU usage, memory usage, swap file creation, and network communication.

- **Software Interfaces**: Libra will interface directly with the modified Sun Grid Engine cluster management system, version 5.3, and will use PVM (Parallel Virtual Machine) and MPI (Message Passing Interface) libraries for executing embarrassingly parallel jobs.

- **Communications Interfaces**: Libra will rely on the communications architecture of the Sun Grid Engine and will not have unique communications interfaces beyond those provided by SGE.

These constraints ensure that the Libra Scheduler is designed to integrate seamlessly with existing systems and adhere to open-source standards.

## 3.7 Software system attributes

### a) Reliability
- The scheduler will not support job migration for the purpose of decreasing resource fragmentation.
- There will be a maximum of 1 bug per thousand lines of code (KLOC).

### b) Availability
- In case of a system outage, the cluster will be down while the Linux operating system boots up, which will take less than five minutes.

### c) Security
- The Libra scheduler will ensure the privacy of user job status.
- It will ensure full control over job execution, so that alteration of scheduling criteria or actual resource allocation is not possible without administrator authority.

### d) Maintainability
- [N/A]

### e) Portability
- All coding will be done in standard C, which is a proven portable language.
- [N/A] for other portability attributes.

## 3.8 Supporting information

[N/A]

## 4.1 Functions

[N/A]

## 4.2 Performance requirements

The verification of performance requirements for the Libra Scheduler will focus on ensuring that the system meets the specified response times, capacity, deadline sensitivity, and cost sensitivity as outlined in the requirements section.

- **Response Time Verification**: The system will be tested to ensure that the maximum response time for the submission of a job does not exceed 1 minute. This will be verified through performance testing under various load conditions to simulate real-world usage.

- **Capacity Verification**: Although there is no inherent upper limit in the Libra scheduler, the system will be tested to ensure that it can handle the maximum number of jobs that the nodes can fulfill within their deadlines. This will involve stress testing with a large number of job submissions to observe system behavior and performance.

- **Deadline Sensitivity Verification**: The Libra scheduler will be verified to ensure that all jobs are completed with a 10% error allowance, assuming accurate job statistics are submitted. This will be tested by submitting jobs with varying deadlines and monitoring the completion times to ensure compliance with the specified error margin.

- **Cost Sensitivity Verification**: The system will be tested to ensure that the maximum cost payable, as submitted by the user, is the maximum cost charged. This will involve submitting jobs with different budget constraints and verifying that the cost charged does not exceed the specified budget.

These performance requirements will be verified through a combination of automated testing tools and manual testing procedures to ensure that the Libra Scheduler meets the expected performance standards under both normal and peak workload conditions.

## 4.3 Usability requirements

[N/A]

## 4.5 Logical database requirements

[N/A]

## 4.6 Design constraints

Verification of design constraints will involve ensuring compliance with the specified constraints on the system design. The following approaches and methods will be used:

- **Parent Component Verification**: Verify that the Libra scheduler functions as a sub-component of the Sun Grid Engine (SGE) without requiring modifications to the SGE or the Linux kernel.

- **Software Language Compliance**: Ensure that all coding is done in standard C, as specified, and verify adherence to the GNU General Purpose License coding standards.

- **Scheduling Constraints Verification**: Confirm that exhaustive searches of all job combinations are not performed and that heuristics are developed and implemented for the scheduling problem.

These verification activities will ensure that the design constraints are met, aligning with the requirements specified in section 3.6 of the SRS.

## 4.7 Software system attributes

### Reliability
- The scheduler will not support job migration for the purpose of decreasing resource fragmentation.
- There will be a maximum of 1 bug per KLOC (thousand lines of code).

### Availability
- In case of system outage, the cluster will be down while the Linux operating system boots up, which will take less than five minutes.

### Security
- The Libra scheduler will ensure the privacy of user job status.
- It will ensure full control over job execution, so that alteration of scheduling criteria or actual resource allocation is not possible without administrator authority.

### Maintainability
- [N/A]

### Portability
- All coding will be done in standard C.
- The entire Libra project is open source, and hence no component of it will be purchased.

## 5.1 Assumptions and dependencies

- The workability of the Sun Grid Engine cluster management system modules, such as those dealing with process migration, with the scheduling policies provided by the Libra Scheduler is assumed.
- A basic module of job accounting and payment considerations will be provided, as they are not the focus of the scheduler.
- Users are assumed to have a fair estimate of job execution times, so that the decision to accept or reject a job is facilitated.
- The current hardware setup consists of a network of four Pentium-III workstations with 128 MB RAM, running on the Linux operating system. A larger number of dedicated workstations would be beneficial for better performance analysis.
- A simulating tool needs to be used for testing purposes, which may have to be specially designed if a generic one is not readily and freely available.
- The pricing mechanism will not affect the scheduling policies, as they assume a given cost and budget, and schedule resources accordingly.
- At present, only a command line Linux interface or the interface of the Sun Grid Engine cluster management system will be used as the user and administrator interface. A GUI might be added once the basic functionality is implemented.
- It remains to be decided whether a software tool for simulation and testing purposes will be designed or a generic one that is freely available will be used.

## 5.2 Acronyms and abbreviations

- **Cluster/Cluster Computing**: Connecting two or more computers to utilize combined computational power and resources.
- **QoS**: Quality of Service – meeting user requirements to maximize utility.
- **Computational Economy**: User-centric resource management based on user-specified QoS parameters.
- **Linux**: An open-source operating system with extensive documentation and user support.
- **Grid Computing**: Infrastructure coupling resources across the Internet, presenting them as a unified resource.
- **Bid-based Proportional Resource-Sharing Model**: Economic model allocating resources based on user criteria like deadline and budget.
- **Stride Scheduling**: Algorithm enforcing resource allocations proportional to user priority or share.
- **Process Migration**: Moving a job from one system to another without restarting.
- **Sequential Jobs**: Jobs that must run on a single node and cannot be split.
- **Embarrassingly Parallel Jobs**: Parallel jobs that can be split into independent parts with minimal inter-job communication.
- **Job Accounting**: Method of quantifying system resources used by a job.
- **GUI**: Graphical User Interface.
- **CPU**: Central Processing Unit of a computer.
- **SGE**: Sun Grid Engine cluster management system.
- **Open-source software**: Software with freely available code for use and research.
- **Homogenous cluster**: A cluster with nodes having uniform characteristics and running the same operating system.