Architecture of the Virtual Labs Hosting Ecosystem

From Virtual Labs Community
Jump to: navigation, search

- by Devi Prasad, Suraj Samal

In this post we explain the proposed architecture of the Virtual Labs hosting system. The solution described here aims to automate the process of publishing and monitoring the labs. More specifically, we develop different models of hosting the labs within Virtual Machines (VMs). We have identified four different models with varying degrees of scalability, availability and security:

  1. One VM per Lab (OVPL)
  2. One Lab in Multiple VMs
  3. Multiple Labs per VM
  4. Labs in the Cloud

Our Design Rationale

The design of this ecosystem is motivated by the following requirements:

  1. to enable secure and automated deployment of Virtual Labs.
  2. to have secure system components which have the ability to protect themselves against
    inadvertent actions and malicious attacks.
  3. to ensure modularity without linking the design to a particular platform or technology.
  4. to ensure easy design, maintenance while enabling efficient implementation.

The design decisions are aimed at improving the overall user experience of the Lab Developers and the end users. By user experience we mean all aspects that otherwise would be catalogued under non-functional requirements. This includes the availability of labs, monitoring the runtime state of the labs, detecting non-responsive labs, provision to pause a lab for administrative and troubleshooting purposes, and so on.

Lab Developer is the chief stakeholder of this system. Once a Lab Developer version-controls the source code of the lab, the system described in this document will allocate and manage hardware and software resources required to publish the lab to the end users.

Here is some elaboration on the requirements:

  1. Enabling secure and automated deployment of Virtual Labs:
    This solution requires Lab Developers to declare the runtime requirements for their labs. Since the Lab Developers have the knowledge of the ecosystem and the system services required to run the experiments, it is logical to require Lab Developers to declare the operating system requirements, and the packages, libraries, and the frameworks required to run their labs.
    For improving the availability and scalability, administrators and Lab Developers may decide to release more than one active instance of a lab to execute in multiple VMs (Multiple Labs per VM model).
    On the other hand, for security reasons, Lab Developers may want to restrict only one execution instance of a lab within a virtual machine (One Lab per VM model).
    Labs may be comprised of different subsystems that are spread across virtual machines. For example, a lab may be realized as two components: one presenting the lab content (i.e., text, images and videos) that the students are expected to comprehend, and the second that allows students to actively interact with an interpreter or an environment for either verifying their understanding or for solving exercises (Labs in the Cloud model).
    Labs that have dense state may also need special setup. Labs that record data pertaining to student performance and store state related to their experiments, for instance, may require multiple virtual machines in order to isolate logically distinct subsystems (Multiple Labs per VM model).
  2. Having secure system components which have the ability to protect themselves against inadvertent actions and malicious attacks:
    The system is designed to use SSH and HTTPS for subsystem and component interactions. All interactions are performed against well-defined APIs that the components expose. No component in the system assumes undue privileges or exercises absolute rights over any resource. Components are designed to rely on the security features of the host operating system and the managed environment within the virtual machine.
  3. Ensuring modularity without restricting the design to a particular platform/technology:
    The design enables extensibility, pluggable components, scalability and availability: we define a layered architecture for the entire system. Components within a specific layer and those across layers communicate against well-defined interfaces.
  4. Ensuring easy design,maintenance while enabling efficient implementation:
    We foresee numerous potential enhancements to the current system. We also imagine these enhancements to be gradually introduced over a period of time. It is therefore crucial that the current design and its implementation is accessible to developers with varied software development experience and background.

The Layered Architecture of our Hosting Environment

The proposed system employs layered architecture for separating various subsystems and concerns. Since the system is composed of different layers of abstractions, it is important to understand the organization of layers and their boundaries. The following figure shows themost essential details. Here is the Layered Architecture of our proposed solution (click to zoom)-


Below, we briefly describe the seven layers:

  1. Hardware, Network Layer
    This layers is the underlying physical hardware and network infrastructure that acts as the backbone of the entire solution. This generally constitutes servers with high-end CPUs, memory and network hardware. They are collocated with data centres and guarantee high availability and redundant power backups.
  2. Host Operating System
    The proposed solution employs CentOS as the host OS. The decision has been based on the wide acceptance of the CentOS within the enterprise community.
  3. Virtualization Layer
    This is a systems-software layer that empowers the guest OS. In the case of KVM, it runs within the host OS and in other cases, will be layered on top of the host OS. This is the technology that makes it possible to share the host OS’s resources among multiple guest OSs.
  4. Lab Virtual Machine
    This refers to a customized virtual-machine along with its OS that runs a lab. Recall that the proposed solution allows different configurations of labs and virtual machines.
  5. Lab Run-time Requirements
    This layer includes various system libraries, frameworks, services, applications and scripts that a lab requires for its execution.
  6. Published Lab
    This is represented by the lab that users can access and run experiments. A lab runs within its VM and is accessed using a published URL.
  7. User Interfaces
    Virtual Labs are accessed using the Web browsers. Many labs are designed to work solely within Web browsers. The proposed solution supports Web browsers running on Aakash and generic Android devices, iOS devices, and other mobile platforms.

Listed here are the other Block Diagrams of our proposed architecture:

Figure (i) Hosting Environment componentscomponents-of-hosting-env.jpeg
Figure (ii) Multiple VM Pools to achieve scalabilitymultiple-vm-pools.jpeg
Figure (iii) Cloud for scalingscaling-with-cloud
Figure (iv): Life Cycle of a ‘lab’life-cycle-of-a-lab

Today’s post we end here. In our next post, we intend to elaborate the four VM models.

This entry was posted in Uncategorized on December 19, 2013 by Jayashree Prasad.

Post navigation

A brief introduction to Responsive Web Design