Problem Statement. Jonathan Huang Aditya Devarakonda. Overview

Transcription

1 Jonathan Huang Aditya Devarakonda Problem Statement Overview Automated job schedulers have been extensively studied and implemented in large clusters and supercomputers. However, many of these clusters do not provide detailed utilization information which users can take advantage of. For example, users working to meet deadlines can utilize the cluster monitoring to make appropriate decisions regarding application deployment. Using a web-based interface will allow users easy access to the cluster monitoring system and job scheduler. One advantage of using the web, is that it provides systems administrators to customize the access privileges for individual users or groups of users. Another consequence of implementing both monitoring and scheduling is the ability to generate prediction models. The models would enable the system to react effectively to jobs currently running and the current cluster utilization. Customers We anticipate that this system would be appealing to anyone who intends to implement a job scheduling system for their clusters and supercomputers. In general, we believe that this High Performance Computing community can benefit the most with this system. This work can, in the future, be scaled-down for administrators managing smaller clusters. Goals Primarily we would like to provide a system which combines job scheduling and cluster monitoring using a web-based interface. This interface can be made accessible over the Internet so that users can monitor the clusters from anywhere. By combining monitoring and scheduling we can take advantage of detailed utilization information and attempt to map jobs to machines efficiently using prediction models - which are generated from the utilization information. Deliverables This project will be implemented in three phases. The first phase will be dedicated to developing the framework of the front and back end portions of the system. The web interface as well as the cluster logging will be implemented. Users will be able to view log files as well as graphs of the data. Individual pieces of work will be allocated to each member to work on due to the size of this phase. During the second phase, the job submission module and preliminary prediction models will be added. Also the interface will be updated for multiple users. Each user will have access to specific content and machines. Users will be able to submit jobs and retrieve the results as well as view expected future utilization generated by the prediction module. In the last phase, the final implementation of prediction models will be implemented. All remaining performance and ease of use improvements will be made. Schedule

2 Date Deliverable 3/30 Main framework of the front and back end 4/13 Multi user system, job submission module and utilization prediction model 5/04 Final version of prediction model and remaining performance and interface improvements. System Functions Evident The front-end will handle all user requests to submit jobs to the cluster and provide cluster utilization information to the user. Coupled with this functionality is the authentication and security protocols which separate one user from another. The back-end is effectively hidden from the user in that they cannot directly look at the application execution. However, the results from each job are available to users hence the application execution is evident at an abstracted level. Hidden The movement of data from front-end to back-end (for cluster setup and application execution) is hidden from the user. Similarly the job scheduler and the prediction models being used are also hidden from the user. The entire back-end is hidden from users accessing the front-end. More specifically, the cluster utilization data collection, application runtime monitoring and transfer of application results/ outputs are also hidden from user. Effectively the users submit their job for execution, monitor the cluster utilization through the front-end and receive results once execution has completed. Although the users can see the utilization information, they cannot see the mechanisms used to collect the information nor alter them. Frill The real-time cluster utilization graphs can allow users to filter information based on their requirements. The capability of filtering results and allowing users to customize the graphs does not change the functionality of the system but provides better usability. A mobile interface would extend the availability such that anyone would be able to access the services provided even when they are roaming and have only a mobile device available. System Attributes

3 Front-End The job scheduler on the front end must be able to access cluster utilization information and implement scheduling algorithms which attempt to produce optimal resource to application mapping. Generating an optimal mapping acts as a constraint for the job scheduler in the sense that any mapping which would delay application execution and degrade cluster performance must be avoided. The prediction model we intend to implement must improve the performance of the cluster and aid the job scheduler in making better decisions regarding resource allocation. In the case, the main constraint for the prediction model is that it must improve upon the job scheduler. Otherwise, utilizing the prediction model would be costly and unnecessary if it does not improve performance. Back-End The cluster information being collected on the back-end is essential to being able to provide utilization graphs and the prediction model. As a result, the collection system must collect data frequently enough to provide enough information but avoid collecting so much information that it disrupts application execution and steals too many processor cycles. Once again, this becomes an optimization problem between collecting enough data and interfering with running jobs.

4 Data Dictionary Document User - By user we mean any person who would use and benefit from this system. For example, application developers, application users and systems administrators can be users of this system. Job Scheduler - This is a sub-system which attempts to optimize the resource provisioning for each job. It implements algorithms which do the optimization by using the cluster utilization information. Prediction Model - This is a sub-system which takes advantage of the cluster information being collected and implements algorithms to use this information to predict future load and latency of the cluster. Cluster - Any set of resources used for computation (desktop computer, datacenters (virtualized and non-virtualized), supercomputers, etc.). Data - This defines the set of information being collected on the back-end. For example we will be collecting Temperature, CPU Utilization and Network Latency. Metadata - This is a collection of requirements specified by the user when submitting a job. This includes information such as expected running time and application profile (CPU-intensive, network intensive).

5 Use Case Diagram

6 Use Case Specifications Log In UCATS001 Description: User accesses the webpage and enters login credentials (username and password) Purpose - This use case is an important part of providing security guarantees when using the scheduling and monitoring features. This also ensures that users are accountable and allows systems administrators to customize resource access to individual users or groups of users. Related Use Cases: View Data and Submit Job Primary Actor: User (Person). Secondary Actor: None. Technical Requirements: Valid username and password, a web browser. Pre-Condition: None. Main Course: 1. The user accesses the website and enters his/her login credentials. 2. The login information is forwarded to the authentication system. 3. The authentication system verifies the username and password. 4. The authentication system returns with success or failure. 5. The user is subsequently forwarded to the welcome page and can use the services. Post-Conditions: The user will have access to their appropriate services. Alternative Course: 1. Username and password cannot be verified and the system will display Issues: 1. Authentication errors must be handled appropriately. Assumptions: 1. The user has entered his/her username or password incorrectly and must be given a retry period. Design Comments: 1. Make the username and password form easily viewable and accessible to the user.

7 View Graph UCATS002 Description : User queries web interface for a graph of defined data. The database returns the appropriate data range, graph code is generated by the back-end and returned to the user s browser. Purpose : This Use Case illustrates the primary data display module available to the user. Related Use Cases : UCATS001 Primary Actor(s) : User(Man) Secondary Actor(s) : Cluster(Machine) Technical Requirements : Browser capable of generating graphs Pre-condition : User must have a valid login to the system. Database must have collected data available. Main Course : 1. User queries web interface for data through the View Graph function. 2. The front-end queries the back-end through the Collect Data function. 3. The back-end sends a request to the database for the appropriate data. 4. When the data is returned, the Graph code is generated from the Create Graph function and returned to the user. Alternate Course : 1. User queries web interface for data through the View Graph function. 2. The front-end queries the back-end through the Collect Data function. 3. The back-end sends a request to the database for the appropriate data. 4. Data is not available, no graph is generated and an error is returned to the user. Issues : 1. Appropriate error checking data values and date ranges. Assumptions : Design Comments : Change Log : 3/2 - First draft implemented.

8 View Prediction UCATS003 Description : User queries web interface for data of a future date range. The database returns data from the range, predicted values are calculated by the back-end and returned to the user s browser. Purpose : This Use Case shows the flow of data required for the prediction modeling. Related Use Cases : UCATS001, UCATS002 Primary Actor(s) : User(Man) Secondary Actor(s) : Cluster(Machine) Technical Requirements : None Pre-condition : User must have a valid login to the system. Database must have collected data available. Main Course : 1. User queries web interface for data through the View Prediction function. 2. The front-end queries the back-end through the Collect Data function. 3. The back-end sends a request to the database for the appropriate data. 4. When the data is returned, the prediction is generated from the Create Prediction function and returned to the user. Alternate Course : 1. User queries web interface for data through the View Prediction function. 2. The front-end queries the back-end through the Collect Data function. 3. The back-end sends a request to the database for the appropriate data. 4. Data is not available, no prediction is generated and an error is returned to the user. Issues : 1. Appropriate error checking data values and date ranges. 2. Insufficient data to perform Create Prediction. Assumptions : Design Comments : Change Log : 3/2 - First draft implemented.

9 Submit Job UCATS004 Description: User submits his/her application to be scheduled for execution using the job submission page. User provides Metdata for their application along with the application. Purpose: This use case is an essential component to submitting jobs for execution and provides an interface for users to submit them. Related Use Case: None Primary Actor: User Secondary Actor: None. Technical Requirements: a web browser. Pre-Condition: Must have a valid login. Main Course: 1. The user uploads their application binary. 2. The user fills out the Metadata form and provides information about application profile and estimated running time. 3. The Metadata is converted into a file used by the job scheduler to queue the job. 4. The application is subsequently scheduled, mapped to resources and executed. 5. After the application completes the user is notified of the job completion. 6. The results from the job are made available to the user. Alternate Course: 1. The user does not fill out the Metadata form. 2. A generic Metadata file is generated and forwarded to the job scheduler. 3. The job is scheduled, mapped and executed. 4. After the application completes the user is notified of the job completion. 5. The results from the job are made available to the user. Issues: Assumptions : Design Comments : Change Log : 3/2 - First draft implemented.

10 Job Scheduler UCATS005 Description: The job scheduler receives the applications and Metadata from the Front-end and schedules the application based on cluster utilization and the application s Metadata. Purpose: This use case is an essential module which allows users to submit their application, optimize the mapping and execute the application. Related Use Case: UCATS004 Primary Actor: Cluster Secondary Actor: None Technical Requirements: None Pre-Condition: A job has been submitted and needs to be scheduled. Main Course - 1. The Job Scheduler receives an application and Metadata. 2. The scheduler runs the scheduling algorithm using the Metadata. 3. The scheduler generates a mapping to resources and queues the application. 4. The application is moved to the execution environment. 5. The application is executed. 6. The application is monitored until termination. 7. The output files generated by the application are returned to the user. Alternate Course - 1. The scheduler cannot successfully schedule due to an error. 2. It generates an error log and forwards it to the user. 3. The user can evaluate the error log. Issues : 1. Designing an appropriate scheduling algorithm. Assumptions : Design Comments : 1. The algorithm must be optimal in its resource allocation and application to resource mapping. Change Log : 3/2 - First draft implemented.

11 Collect Data UCATS006 Description : Cluster is periodically queried by the system in order to pull log data. This data is saved into the database for future use. Purpose : This Use Case highlights the back-end interactions between the system and the cluster. Related Use Cases : UCATS001, UCATS002 Primary Actor(s) : Cluster(Machine) Secondary Actor(s) : None Technical Requirements : None Pre-condition : None Main Course : 1. System accesses the cluster machines at a periodic rate with the Collect Data function. 2. The cluster machines will return the requested log files. 3. These logs are parsed by the back-end via the Process Data function and sent to the database. Alternate Course : 1. System accesses the cluster machines at a periodic rate with the Collect Data function. 2. One of the machines fails to respond within the time-out period allocated. 3. No data is inputted for that machine in the database while all the other collected data is inputted. Issues : 1. Appropriate error checking data values. 2. Assigning reasonable time-out periods for data collection. Assumptions : Design Comments : Change Log : 3/2 - First draft implemented.