Architecture Document
Our client, Brian Klimaszewski, communicated to us that he needs a way to manage virtual machines without his intervention. He currently spends too much time creating Virtual Machines for various projects for his company. Each step takes hours to accomplish, such that in order to create a single virtual machine, it consumes his entire day. Thus, he has asked us to automate this process by creating a web application which would allow his employees to request machines within a browser. This document describes the architecture of our automated solution to his problem.
Please see Requirements.
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 the platform or the virtual machine manager software we use. The client is currently solely interested in creating a web application, so there should be little chance of a change in front-end. Since the potential exists for additional clients, including people who may access our project in the future on GitHub, the separation will allow the same frontend to communicate with multiple backend types.
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.
General operations that result in out-of-date information will be coded in such a way as to prevent problems in the future (made atomic). As an example, the getNextIPAddress() function that resides in the Persistence API backend will need to allocate that particular IP address so that a concurrent user does not attempt to create a machine with the same address. If the user cancels the request to make a new machine, then it should release that temporarily allocated address back into the pool.
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.
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.
The solution is split into a back-end and a front-end (see [Framework](Architecture-Document#wiki-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.
The VMs will actually be hosted on a second physical machine, running some version of VMware software, and not the web server.
We chose to structure the solution in this way because our client uses VMware to create virtual machines.
The purpose of this view is to show the data dependencies between various database objects
The Image Record structure is designed to track the current VMware images that our interface supports. These images are base Operating Systems with pre-configured software installs. The image records should be modifiable by the admin interface on the front-end by way of the persistence APIs described in the [Framework](#framework) section below.
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 Image Record.
Below is the layer diagram for a basic VM query.
The frontend will interact with the backend through a specific, well-defined interface.
-
This interface will allow:
- creating a new VM
- querying VM info
- updating the vm information fields
- setting server configuration data.
-
The backend will utilize the Persistence API to enable caching and store information and the Virtual Machine Information API to communicate with the VMware Server.
-
The backend API is where the decision is made about whether information is queried or pulled from cache.
This subsystem of the backend will perform the actual communication with the VMware server to query dynamic data and execute actions on the VMs. It will not be directly used by anything other than the backend.
This subsystem will wrap VMwareTasks, which is an open-source library allowing C# project to communicate with VMware servers. VMwareTasks, in turn, wraps the VIX API, an official VMware software which communicates with VMware servers of all types.
The 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. The interface needs to support concurrent access and writing to the file so that users modifying virtual machines from different locations do not overwrite each others' data. The application will use the Entity Framework to enforce optimistic concurrency on the data entities. The list of queriable data items and statically stored data items is listed in the requirements document.
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.
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