Prototype Architecture

In order to develop our ad hoc cloud computing platform, we have used our virtualized volunteer infrastructure V-BOINC as a foundation to build on and extend. Therefore we inherit many of the functionalities V-BOINC has to offer as well as an initial client-server architecture.

We now give an architectural overview of the ad hoc cloud while focussing on the differences when compared to the V-BOINC server and client components. We then outline how these components interact and give an overview of how the ad hoc cloud operates. These descriptions are then used in subsequent sections to describe in greater detail the implementation and features of the ad hoc cloud.

4.3. Architecture of the ad hoc Cloud 87

4.3.2.1 Thead hoc Server

The ad hoc server is an extension of the V-BOINC server previously described in Chap-ter 3. While an ad hoc and V-BOINC server share one primary purpose of distributing virtual machines to volunteer hosts, the ad hoc server is able perform more complex operations. Unlike a V-BOINC or regular BOINC server, the ad hoc server is able to:

• allow ad hoc cloud users to submit jobs to BOINC,

• schedule cloud jobs and virtual machine migrations to near-optimal ad hoc hosts based on host availability, specifications, resource load (i.e. the current utiliza-tion of a resource) and reliability,

• send instructions to ad hoc hosts for execution,

• monitor and manage the state of the system easily.

These additional functionalities help transform our V-BOINC infrastructure into one half of an ad hoc cloud computing platform. We are able to provide these functionali-ties by creating two BOINC projects: VM Service and Job Service. This is in contrast to our V-BOINC server where volunteer users are served from a single BOINC project named V-BOINC. The architecture of the ad hoc server is shown in Figure 4.4.

The ad hoc Server

Figure 4.4: The ad hoc Cloud Server Architecture

The Job Service project has the purpose of receiving cloud jobs from ad hoc cloud users, via the ad hoc Cloud Interface, and registering these jobs with BOINC. Once registered, the Job Service has the task of informing the VM Service that the cloud job is ready to be executed on an ad hoc guest running on an ad hoc host. The ad hoc Cloud Interface also allows ad hoc cloud users and ad hoc server administrators to manage their respective BOINC accounts.

The VM Service project, conceptually similar to the V-BOINC project that runs on a V-BOINC server, has the task of distributing virtual machines to ad hoc hosts.

Additionally, the VM Service project schedules jobs to near-optimal ad hoc hosts and virtual machine migrations, sends instructions to both ad hoc hosts and ad hoc guests and monitors and controls the entire system state. Ideally it would be beneficial for development and management purposes if both cloud jobs and virtual machines could be served from a single BOINC project however this is not possible as we need to distinguish between the two entities to allow the former to execute on the latter. Al-though the ad hoc server is substantially different to a regular BOINC server and offers a greater number of features, we have ensured that architectures of both have remained similar; a comparison can be made between Figures 4.4 and 2.8. We describe how the ad hoc server is able to offer the outlined features in greater detail later in the chapter.

4.3.2.2 Thead hoc Client

The ad hoc client is an extension of the V-BOINC client previously described in Chap-ter 3. While an ad hoc and V-BOINC client share the primary purpose of executing volunteer applications that run volunteer host virtual machines, the former has a greater number of responsibilities, in particularly to help provide a reliable environment for job execution. Unlike a regular BOINC or V-BOINC client, the ad hoc client is able to:

• receive instructions from the ad hoc server to be executed,

• periodically take checkpoints of the virtual machine,

• schedule and send checkpoints to a near-optimal number of ad hoc hosts,

• receive virtual machine checkpoints from other ad hoc hosts,

• restore virtual machine checkpoints sent from previously terminated or failed ad hoc hosts or guests,

• effectively monitor both ad hoc hosts and guests.

4.3. Architecture of the ad hoc Cloud 89

Due to the large number of features integrated into the V-BOINC client to create the ad hoc client, the architectures of both are significantly different with the latter being more complex. The architecture of the ad hoc client is shown in Figure 4.5.

The ad hoc Client

Figure 4.5: The ad hoc Cloud Client Architecture

We see that the ad hoc client is composed of six major components: the ad hoc Client Interface, Communication, Listener, VM Operations, DepDisk and Reliability. The ad hoc Client Interface provides a GUI, similar to the BOINC Manager (see Section 2.4.3 of Chapter 2), to control the ad hoc host’s membership within the ad hoc cloud. The Communication component interacts with the ad hoc server while the Listener listens for any instructions sent from the server to be executed. This may include performing operations on the virtual machine via the VM Operations component which has the responsibility of dealing with all aspects related to the interactions between VirtualBox and the virtual machine.

The DepDisk component checks the ad hoc server for dependency disks and down-loads the correct DepDisk for an application if it requires it. Finally and most impor-tantly, the Reliability component ensures the continuity of cloud jobs by periodically taking virtual machine checkpoints and distributing these in a P2P fashion within a cloudlet; a set of connected ad hoc guests that provide a particular service or execution environment, i.e. those that possess the same application dependencies and DepDisk.

We describe how the ad hoc client is able to offer the aforementioned features via the six major client components in greater detail later in the chapter.