Storage Management in the Cloud with QoS Application Design Document

1. Storage Management in the Cloud with QoSApplication Design Document Gal Lipetz NetaliAlima Chen Ackerman ShimiMalka

2. Vision The goal of our project is to provide performance management for enterprise disc arrays taking into account QoS specifications.

3. System Architecture

4. Data Model

5. Use Case:Gengerate Query

6. Behavioral AnalysisAlgorithm Sequence Diagram

7. Object-Oriented Analysis

8. Packages • Header Files – Includes all of the h files that contain the system’s actions and activities, such as the parser, the algorithms, the correlation calculations etc. • Source Files – Includes all of the cpp files that contain the system’s actions and activities. • Header System Objects – Includes all of the system’s data objects h files, such as the extents, LUNs, etc. • Source System Objects – Includes all of the system’s data objects cpp files. • Gui- Includes all of the system’s Interface classes. • Resource Files – Includes the configuration and input files.

9. Main Classes • Parser –Responsible for parsing the input files. • Writer – Responsible for creating relevant data into output files. • Sorter –Responsible for all sorting algorithms used in the data placements algorithms. • SystemView – All of the system’s parameters are saved in this class.

10. Main Classes Cont… • LunsCorrelation – Calculates the similarity between LUNs. • TimeSliceCalculations – Calculates the response time and damage for each LUN, for the current time slice. • OptimalAlgo – The optimal data placement algorithm, used for comparisons with other algorithms. • NextAlgo – A data placement algorithm in which memory assignment is based on previous time slices.

11. Main Functions • Algorithm: runAlgo()Precondition : SystemView object and all DeviceData objects were created. Postcondition : The algorithm’s hit ratio, all of the devices’ utilizations, and all LUNs’ response times for each time slice were calculated. • DeviceData: calcUtilization ()Precondition : All trace data was parsed and one of the algorithms started running.Postcondition : All of the three DeviceData objects contain the new utilization for the device. • LunTimeStatistics: responseTime() Precondition : The LUN’s extents’ device placements were calculated. Postcondition: the response time for the current time slice was updated.

12. System States Parse Input Store Data Run Algorithm Parsed Data Algorithm Chosen Data Desired Algorithm Rules and Decisions Data Desired Solve Query Get Data QoS Input Result Simulate QoS Input Input Files Query Results Gui Ask Query Parse Data Device Allocation Device Groups Solve Algorithm Main Menu

13. User Interface Draft

17. Testing • Data Simulator • Simulates data from the machine. • Receives parameters and creates a data file with the desired characteristics. • Using the parameters we can calculate what the system’s outcome should be and verify the correctness of our system. • Real Data • System runs with real data. • System completes tasks without errors. • Results required are shown and relevant graphs created.

18. Non Functional Requirements Testing • Speed • Algorithm Simulation and parsing completes in under 12 hours. • Queries give an answer after 2 minutes. • Reliability • When using simulated data the system’s outcome will always as predicted. • Platform Constraints • Input files – Does not crash with incorrect input format. • Output files – Output is received in the required format with the relevant graphs.

19. Task List • Complete models, including priorities • Add damage calculations and graphs • Calculate System Size • Optimize Algorithms • Optimize Parsing and Memory Usage • Implement Additional Algorithms • Test all logics in the project • Create and test GUI • Draw conclusions and derive recommendations