User:Ime-tpoo
From Wikipedia, the free encyclopedia
This page contains the result of Design Fest . It was done at IME - USP.
Enterprise Storage Management System .
Colaborators: Helves Domingues, Igor Rascovsky, Marco Netto, Renato Miyasaki, Ricardo, Rodrigo Lopes.
Contents |
[edit] Problem Description
The problem Enterprise Storage Management System proposed by Dan Glasser, Madeline Hardojo, Anand Sundaram, Nate Wells, Mohamed Fayad (Computer Science & Engineering, University of Nebraska, Lincoln) is available at DesignFest® Problem Collection (in the 2002 edition).
Following is the problem general idea. The complete descrition can be downloaded here.
"Enterprise Storage Management System is an interactive and user-friendly program that will enable the Lincoln Telephone Company to efficiently manage their storage system. With this system, the Lincoln Telephone Company will be able to monitor the file system in the storage, optimally backup; both manually and automatically, recover their data while maintaining its correctness, and provide statistic information as a reference for the system administrator. The system also provides some maintenance functions such as identifying bad or full disks, assigning and redirecting available resources while keeping the integrity of the system, and compressing the inactive files."
[edit] Proposed Solution
Basically, the proposed solution is to include in each application server a service to interact with the main backup system module. With this solution, each module can control the system actions and each server will be able to perform backup procedures concurrently.
[edit] Structure
The sistem is composed of four nodes:
1) Client: responsible for accessing the user data and application;
2) Application: responsible for executing applications and keeping the data disks. Moreover, each one of these nodes executes a system backup agent;
3) Backup: stores the backup data and executes an agent that performs the backup procedures;
4) Dispacher: receives notifications both from agents and from administrator users, as well as dispaches configured procedures.
[edit] Dynamics
In order to attend the requirements, the proposed system was designed as a distributed architecture. Agents collect information for the application servers and generate notifications that are sent to the Dispacher. The last then process these notifications and perform procedures according with the its configurations. These procedures may comprise events to data agents in the backup servers.
1) Request Backup: It is a user request that contains the directory or the file that needs to be backup.
2) Collect Information : The Dispacher must know some information about the file or the directory received in the request. The way to obtain this information is to ask the Data Agentt that is running in the application node that this file or directory exists.
3) Perform Backup: After the Dispacher received the information from Data Agent, It can request the Data Agent perform the backup. In this request the Dispacher will inform which Backup Agent that the Data Agent has to comunicate to perform the backup.
4) Start comunication: The Data Agent must start comunication with the Data Agent to verify the bandwith, negotiate the protocol and inform the Data Agent about size of the backup archive that will be transmitted.
5) Transfer Data: The Data Agent will transfer all files to Backup Agent. When Backup Agent receive the file, It will be compressed and written in the local discs.
[edit] Conceptual Model
At this section we describe some important elements of class diagram to best understanding of our proposed solution.
1) Server: This class and all other associated with Disc are a model of the hardware and its discs. This part of the diagram represent how the solution view the environment.
2) Disc: The solution has two kind of Disc: Production disc (Prod) and Backup. All discs in the application node are Production discs and all discs in the Backup node are Backup discs.
3) Node: This class and Diirectory (Dir) and File classes are a composition modeling of the Server file system.
4) Backed: It is the representation of one execution of back-up action. This class is associated with Node because the user can request a backup of a directory or a file.
5) Backup Archive: This class is the logical representation of one backup archive.
6) Physical backup: It is a physical representation of the backup archive. The solution has these two classes of backup: Logical and Physical, because the request to implement a distributed backup. In this way, if a backup is two large, for example, one terabyte, the system can split this archive in gigabytes physical backup and distribute each of this small archive to differente backup node.
7) Event Handler: This abstract class represent all possible event that this system can handle. Some events identified from the problem are: Over Threshold, Log Event, Schedule backup, Bad Disc and Backup Failure.
8) ESMS: Enterprise Storage Management System (ESMS) is the main class of the system. This class is the controller that implement the backup tasks and comunicate with the agents.
9) Agent: The solution has two kind of agent: Data Agent that runs in application node, and Backup Agent that runs in the backup node.
10) Action: It is the defined actions that any agent can do.
