| Content Team Problem Description Proposed Solution Overview Structure Dynamics Conceptual Model Concluding Remarks |
Team
Helves Domingues (recorder), Igor Rascovsky, Luis Ricardo, Marco A. S. Netto (moderator), Renato Miyasaki, Rodrigo Lopes.
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 description 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."
Proposed Solution Overview
Briefly, 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 is able to perform backup procedures concurrently.
Structure
The system 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) Dispatcher: receives notifications both from agents and from administrator users, as well as dispatches configured procedures.
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 Dispatcher. 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 Dispatcher must know some information about the file or the directory received in the request. The information is obtained by asking the Data Agent that is running in the application node that this file or directory exists.
3) Perform Backup: After the Dispatcher receives the information from Data Agent, it can request the Data Agent to perform the backup. In this request the Dispatcher will inform which Backup Agent that the Data Agent has to communicate to execute the backup procedure.
4) Start Communication: The Data Agent must start communication with the Data Agent to verify the bandwidth, negotiate the protocol and inform the Data Agent about the backup archive size that will be transmitted.
5) Transfer Data: The Data
Agent will transfer all files to
the Backup Agent. When Backup Agent receives the file, this file will
be compressed
and written in the local disks.
Conceptual
Model
At this section we describe some important elements of class diagram
for a
better understanding of our proposed solution.
In the figure below, the blue color classes represent the event
handler, while the red color ones represent the abstraction of the
file system.
1) Server: This class and all others associated with Disk represent a model of the hardware and its disks. This part of the diagram represent how the solution interacts with the environment.
2) Disk: The solution has two kind of Disks: Production disk (Prod) and Backup. All disks in the application node are Production disks and all disks in the Backup node are Backup disks.
3) Node: This class and Directory (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 either a directory or a file backup.
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 implements a distributed backup. In this way, if a backup is too large, for example one terabyte, the system can split this archive in gigabyte physical backups and distribute each of these small archives to different backup nodes.
7) Event Handler: This abstract class represents all possible events that this system can handle. Some events identified from the problem are: Over Threshold, Log Event, Schedule backup, Bad Disk and Backup Failure.
8) Dispatcher: This is the main class of the system. It is the controller that implements the backup tasks and communicates with the agents.
9) Agent: The solution has two kind of agents: 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.
Concluding Remarks
This experience with DesignFest at IME-USP was very interesting in the sense that we had to deal with a difficult problem in a short period of time. This was not easy mainly because the participants had different background and hence different point of view of the problem. One of the main challenges was trying to develop a simple solution in order to finish it at a time.