## 1.1 Purpose

This Software Requirements Specification (SRS) outlines the requirements and specifications for Libra, an Economy-Driven Cluster Scheduler. The document details 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, focusing on user utility rather than system performance considerations.

## 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 management on homogeneous clusters, the functionality can be adapted for other resources and heterogeneous clusters in the future. The Libra 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 component 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 approach to scheduling batch jobs. The Libra Scheduler interfaces with SGE to receive job submissions and communicates its scheduling decisions back to SGE for execution on the appropriate workstations.

#### System interfaces
Libra interfaces with the Sun Grid Engine, which handles job submissions and resource management. The scheduler communicates its decisions regarding workstation allocation to the resource manager, which then dispatches the job to the chosen workstation. No modifications to the Linux kernel are required.

#### User interfaces
The Libra Scheduler 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 parameters. 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, 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 automated scheduling operations. It dynamically reallocates resources based on user priorities and constraints, such as budget and deadlines, to optimize job scheduling and 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**: Users can submit jobs with specific parameters such as location of executable, input data sets, execution time, and whether the job is sequential or embarrassingly parallel. The scheduler will prioritize jobs based on user-defined criteria like budget and deadline.

- **Job Scheduling**: The scheduler allocates resources based on user-centric priorities, using a bid-based proportional resource-sharing model. It dynamically adjusts resource allocations to meet user demands, ensuring that jobs with urgent deadlines and higher budgets are prioritized.

- **Resource Allocation**: The scheduler enforces resource allocations proportional to user priorities using the Stride Scheduling Algorithm. This ensures that jobs receive CPU time according to their allocated budget and deadline.

- **Job Monitoring and Management**: Users and administrators can view job status, modify job parameters, and delete jobs. The system provides options to monitor the progress of job execution and manage job queues.

- **Cluster Management**: The scheduler updates cluster status with each job execution, ensuring efficient resource utilization and load balancing across nodes. It also provides administrative security and basic job accounting.

- **User and Administrator Interfaces**: The system offers command-line interfaces for both users and administrators to interact with the cluster, submit jobs, monitor status, and manage resources.

These functions collectively aim to maximize user utility by optimizing resource utilization within user-imposed constraints, ensuring 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 requires a high level of technical expertise to manage and configure the system effectively. 

Both user groups are expected to have a technical background, with administrators requiring a more advanced level of expertise. There are no specific accommodations mentioned for users with disabilities.

### 1.3.4 Limitations

a) **Regulatory requirements and policies:** Libra will be released under a GPL license and will be open-source.

b) **Hardware limitations:** The current hardware setup for testing includes a network of four Pentium-III workstations with 128 MB RAM each. 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. It will also use PVM (Parallel Virtual Machine) and MPI (Message Passing Interface) libraries for executing embarrassingly parallel jobs.

d) **Parallel operation:** Libra is designed to manage sequential and embarrassingly parallel batch jobs on a homogenous Linux cluster.

e) **Audit functions:** Libra will provide at least a basic level of job accounting to aid in scheduling policies.

f) **Control functions:** Libra will ensure full control over job execution, preventing 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 security provided.

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 Libra.

## 1.4 Definitions

- **Cluster/Cluster Computing**: Connecting multiple computers to leverage combined computational power and resources, providing a single system image across nodes for high-performance applications.

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

- **Computational Economy**: Incorporating user-specified QoS parameters with jobs, 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**: Using a grid infrastructure to couple resources across the Internet, presenting them as a unified resource for processing jobs.

- **Bid-based Proportional Resource-Sharing Model**: An economic model allocating resources based on user criteria like deadlines and budgets, using tokens or credits for resource access.

- **Stride Scheduling**: A scheduling algorithm enforcing resource allocations proportional to user priority, 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 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 with nodes having uniform characteristics, running the same operating system.

# 2 References

## Compliance
[N/A]

## Guidance
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.

Sources for these references can be obtained from academic libraries or online databases such as IEEE Xplore and university repositories.

## 3.1 Functions

The Libra Scheduler is designed to manage and schedule jobs on a cluster by maximizing user utility through a market-based economy-driven approach. The following subsections describe the fundamental actions and processes involved in accepting, processing, and generating outputs for the Libra Scheduler.

### 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 whether the cluster is accepting submissions and if the user is verified.

### 3.1.2 View Job Status
- **Inputs**: User ID and password.
- **Processing**: Displays available options and progress of job execution to the user.
- **Outputs**: User view of job status and 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 submitted by the user and job ID assigned by SGE.
- **Processing**: Retrieves job details and sets variables representing the cluster state.
- **Outputs**: Set variables representing job information.

### 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 value for job acceptance and suggested deadline or cost.

### 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 the least loaded host and appropriate queue for job execution.
- **Outputs**: Chosen execution host and queue.

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

### 3.1.9 Update Cluster Status
- **Inputs**: Job details and chosen execution host and queue.
- **Processing**: Reserves resources, updates execution host queue status.
- **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.

### Validity Checks and Error Handling
- **Validity Checks**: Ensure user authentication and job parameter validation.
- **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 validation, scheduling, and execution.
- **Formulas for Input to Output Conversion**: [N/A]

The functional requirements are organized into sub-functions to facilitate understanding and implementation, though this does not dictate the software design structure.

## 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.

[N/A]
- The number of terminals to be supported.
- The number of simultaneous users to be supported.
- The amount and type of information to be handled.
- The numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.

## 3.3 Usability requirements

The Libra Scheduler aims to provide a user-friendly experience for both cluster users and administrators. Usability requirements focus on ensuring that users can effectively and efficiently interact with the system, achieving their goals with satisfaction and minimal risk of error.

- **Effectiveness**: Users should be able to submit jobs, monitor their status, and manage job parameters with ease. The system should provide clear feedback on job submissions and status updates to ensure users can complete tasks successfully.

- **Efficiency**: The interface should allow users to perform tasks quickly, minimizing the time required to submit jobs and retrieve job status information. The system should respond to user actions, such as job submissions, within a maximum of one minute.

- **Satisfaction**: The system should be intuitive and easy to navigate, reducing the learning curve for new users. A command-line interface will be available initially, with plans to develop a graphical user interface (GUI) to enhance user satisfaction.

- **Avoidance of Harm**: The system will ensure the privacy of user job status and prevent unauthorized alterations to job execution and scheduling criteria. Only authorized administrators will have the ability to modify critical parameters, ensuring secure and controlled access.

- **Accessibility**: The system should be accessible to users with varying levels of technical expertise, providing clear instructions and support for job submission and management.

These usability requirements are designed to ensure that the Libra Scheduler meets the needs of its users while maintaining high standards of quality and security. [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.

- **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.

These constraints ensure that the Libra Scheduler is developed in a manner consistent with existing systems, legal requirements, and project goals.

## 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

a) [N/A]

b) Supporting or background information that can help the readers of the SRS includes Appendix A, which contains background research on cluster computing, market-based economic models, cluster scheduling, and cluster management software.

c) The problems to be solved by the software include providing 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. The main objective is to provide Quality of Service (QoS) computational economy in cluster computing.

d) [N/A]

The SRS does not explicitly state whether these information items are to be considered part of the requirements.

## 4.1 Functions

[N/A]

## 4.2 Performance requirements

The verification of performance requirements for the Libra Scheduler will involve testing both static and dynamic numerical requirements to ensure they meet the specified criteria.

### Static Numerical Requirements
- **Capacity Testing**: Verify that the system can handle the maximum number of jobs schedulable, which is limited only by the capacity of the nodes to fulfill the jobs’ deadlines. There is no inherent upper limit in the Libra scheduler.
- **Response Time**: Ensure that the maximum response time for the submission of a job does not exceed 1 minute.

### Dynamic Numerical Requirements
- **Deadline Sensitivity**: Test that all jobs are completed with a 10% error allowance, assuming submitted statistics for jobs are accurate.
- **Cost Sensitivity**: Confirm that under all circumstances, the maximum cost payable as submitted by the user is the maximum cost charged to the user.

Verification will involve simulating various workload conditions, including both normal and peak workloads, to ensure that the system's performance remains within the specified limits. Performance metrics will be collected and analyzed to verify compliance with the requirements.

## 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**: Confirm that the Libra scheduler functions as a sub-component of the Sun Grid Engine (SGE) without requiring modifications to the SGE or Linux kernel. This will be verified through integration testing with the SGE.

- **Software Language Compliance**: Verify that all coding is done in standard C, as specified. This will be checked through code reviews and automated static code analysis tools.

- **Scheduling Constraints Verification**: Ensure that the scheduling algorithms do not perform exhaustive searches of all job combinations. Heuristic methods will be developed and tested to confirm they meet the scheduling requirements without exhaustive searches. This will be verified through algorithm analysis and performance testing.

These verification methods will ensure that the design constraints are adhered to, maintaining the integrity and performance of the Libra scheduler within the specified limitations.

## 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 a 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, which is a proven portable language.
- The Libra scheduler will be a sub-component of the Sun Grid Engine (SGE), and it will run on a Linux-based cluster.
- [N/A] for other portability attributes.

## 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.

## 5.2 Acronyms and abbreviations

- **Cluster/Cluster Computing**: Connecting multiple 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 support.
- **Grid Computing**: Infrastructure coupling resources across the Internet for unified resource usage.
- **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 between systems without restarting.
- **Sequential Jobs**: Jobs that run on a single node and cannot be split.
- **Embarrassingly Parallel Jobs**: Parallel jobs with independent parts that can be split across nodes.
- **Job accounting**: Method of quantifying system resources used by a job.
- **GUI**: Graphical User Interface.
- **CPU**: Central Processing Unit.
- **SGE**: Sun Grid Engine cluster management system.
- **Open-source software**: Software with freely available code for use and research.
- **Homogenous cluster**: Cluster with nodes having uniform characteristics and running the same OS.