Architecture Document
Our client communicated to us that he needs a way to manage virtual machines without his intervention. This document describes the architecture of our automated solution to this problem.
Our client, Brian Klimaszewski, currently spends too much time creating Virtual Machines for various projects for his company. Each step took hours to accomplish, such that in order to create a single virtual machine, it would consume his entire day. Thus, he has asked us to automate this process.
In order to keep our project modifiable, we have implemented a level of abstraction by having both a front-end and a back-end. This allows us to quickly change either what platform we use, or what virtual machine manager software we use. Unfortunately, there's no way to safeguard against a change of both; however, the client is currently solely interested in creating a web application, so there should be little chance of a change in front-end.
The persistence module needs to handle concurrent access to the data file for virtual machine and image file information. We will use an Excel database file as our method of storage. There is a library in ADO.NET that allows us to connect to this file and use it like a database through a COM object. COM objects support serialization in the same as databases, so concurrent reading and writing to the file will have native support within the controller for managing simultaneous modifications.
6A. Component and Connector
The purpose of this view is to show how information gets passed through the system, and what happens when information is transferred.
This diagram intends to show the general flow of data in our solution. We can see that the front-end communicates directly with the back-end to make requests and get updated about information that may have changed. The back-end communicates with the two APIs described below in Framework in order to update the persistence files to include new requested project/server combinations, and to actually perform the copy, backup, configure, and archive operations that the user may request.
Variability?
We chose to have two separate projects for the front-end and the back-end because it allows for one person to edit one while another edits the other, without fear of having any merging conflicts. Furthermore, if we move to Hyper-V, we can maintain our front-end code, and only have to change the back-end.
The current back-end uses a VMware API that is platform compatible with all versions of VMware relevant to this project.
6B. Allocation
The solution is split into a back-end and a front-end (see [Framework](#framework) below). The possibility of running the front-end and the back-end on two different physical machines was discussed, however, difficulties arising from communication between the two involving concurrency and stability were raised making the thought impractical. Since the original purpose of splitting the solution into front-end and back-end was to allow for re-usability, further discussion of the split has ended.
Picture
Context diagram – virtual machines that get created/how they’re modified
Variability?
We chose to structure the solution in this way because our client uses VMware to create virtual machines.
6C. Module
The purpose of this view is to show the module.
6D. Data
The purpose of this view is to show the data dependencies between various database objects
The ISO Record structure is a persistence structure which is designed to track the current VMware images that our interface supports. It should be modifiable by the admin interface on the front-end by way of the persistence APIs described in the [Framework](#framework) section below. Images are not only ISOs--it was merely a name chosen at the time. It will more likely refer to zipped up backups of virtual machines.
The Project Record structure is an persistence structure which describes a particular project/machine combination, by tracking the attributes shown above. A project has a machine which in turn refers to a particular image described in the ISO Record. # 7. Framework ## Back-end API
The front-end interacts with the back-end mainly through four methods:
VMInfo GetInfo(string imageFileName) : Given a name, looks up all info about the VM
VMInfo CreateVM(VMInfo info) : Create VM using provided info (Created, LastRunning fields ignored). Assume that IP is not already taken (tracking is done by front-end; can switch to back-end)
void UpdateLifecycle(string imageFileName, VMLifecycle newLifecycle) : Mark server as active, idle (pause & don’t autostart), or archived (stops & archives)
void UpdateStatus(string imageFileName, VMStatus newStatus) : Start up, shut down, or pause server
## Persistence APIThe data file for storing static information about virtual machines requires a simple interface so that code can easily interact with the file without having to manually create a method for writing to the file.
string GetImageMetadata(string imageFileName) : Read the stored metadata for the given image file.
void SetImageMetadata(string imageFileName) : Write the given metadata for the selected image file.
Much of the required data for each of the virtual machines can be pulled dynamically from VMware.
We would like to acknowledge our client, Brian, and us four developers: Anthony, Calvin, Jacob, and Nathan. We would like to thank Darryl Mouck for his contributions toward the project, including getting us a virtual machine and helping us fix a problem with our server. Finally, a special mention to our fearless advisor, visiting professor Alex Lo.
None
11A. Glossary
Image - a file that represents the contents of a data storage medium
VMware – software used to create and manage virtual machines
Virtual Machine – a machine running on a host machine that uses the host machine’s resources rather than having any of its own