A Xen-based system, called Cloud Master, is designed and implemented to mimic a cloud platform for on-demand provision and management of virtual machines (VMs). This system provides Java APIs for starting a new virtual machine or stopping an already-started one at runtime. So clustered or distributed applications, running on this sytem, could scale up or down by adding or removing a node which is hosted within a virtual machine. The system layout is shown in Fig.1 below.
Fig.1. The system layout of the mimic cloud platform
In the layout, there are several key components: VM templates, Control Scripts, Control Center and Control APIs. Another component Status Collector is used for virtual machine status collection. The system provides different functionalities for the end user and the system administrator.
In an end user’s view, the system exposes the functionality of on-demand VM provision: starting and stopping a virtual machine. From top layer to bottom one in the system layout, when the Control Center receives a request from a client(maybe an application) who calls the Control APIs, it runs a corresponding Control Script in an appropriate remote xen server through ssh connection. The script will invokes the xm command which will start a new virtual machine or stop a running one. In addition, the system could collect the runtime status(such as the usage of CPU, memory and network) of a virtual machine in two ways: enable the collection in the xen server level, or run the Status Collector in the virtual machine level.
In a system administrator’s view, the system could also manage the resources in xen servers, such as memory, CPU and network. The administrator could add a new xen server to the system by providing the ip, user name and password of the server to the system through a configuration file. Currently, it is not possible to add new xen servers on-line, because we have no such requirement in our virtualization environment. However, it is quite easy to achieve this by adding a new webpage and some Java codes.
To understand the design and details of the system, it is better to explain the functionality of each component from the bottom layer to the top one in the system layout. The following paragraphs will explain the components of the system in details.
First, the VM templates are used to created new virtual machines. They are image files of pre-configured virtual machines with all the necessary software, runtime dependencies and other useful components. For example, in order to provide JRE environment in every created virtual machines, we pre-install JRE in all VM templates. Virtual machines, created from these templates, automatically have JRE environment to run Java applications. Of course, each newly-created virtual machine has its own network configuration(including IP, mac address, and hostname). The templates are stored in one NFS server, so that the templates could be mounted and accessed in every xen server. A xen server is a Linux server with xen hypervisor, which could host and run multiple virtual machines within a single physical machine.
Second, the Control Scripts are used to wrap the invocation of xm commands for the management of virtual machines. In this way, the control scripts can do some extra work, like parameter validation, before invoking the xm commands. These scripts include, but do not limit to, operations such as creating VMs from templates in NFS Server, starting VMs, stopping VMs, and collecting VMs’ statuses. These scripts are uploaded to the xen server when the server is added to the Control Center.
Finally, the Control Center, a J2EE web application within a Tomcat server, is the brain of the mimic cloud platform. It serves as a central manager of the whole system. It not only maintains the information of physical xen server configured in a system configuration file, but also holds the information of available virtual machines in all xen servers. Via the Control APIs exposed by the Control Center, a client could send a request for a new VM or to stop an existing VM. If the client asks for a new VM, the Control Center will check whether there is enough memory in some xen server to serve a new virtual machine. If so, it will dynamically start one VM in that xen server and return the ip of the newly-allocated VM to the client. Otherwise, the Control Center will return an error message to the client. If the client requests stopping a VM, the Control Center will stop the VM. In addition, the starting/stopping operations are done by invoking the remote Control Scripts within xen servers through ssh connection with the help of jsch-0.1.43.jar, a Java library of ssh protocol. Because of the limited performance of I/O in our hard disks, we create new virtual machihnes in a xen server before adding it to the mimic cloud system. We create virtual machines by a script which will make a local copy of a VM template from the NFS server.
In addition, we provide a component, called Status Collector, as an Java library to collect the real-time system status of a virtual machine. This component is running within the virtual machine. The collected statuses could be used by applications within the virtual machines. This status collection is in virtual machine level, decided by the clients of the system. Also, the system administrator could trigger status collection in xen server level, by enabling the system to run a dedicated Control Script periodically to collect statuses of all virtual machines within a xen server. In these two levels of status collection, the collected runtime status will be sent to and saved in the Control Center and could be used for later analysis of the application behaviors.