Virtual machine Allocation

3154 words (13 pages) Essay in Information Systems

23/09/19 Information Systems Reference this

Disclaimer: This work has been submitted by a student. This is not an example of the work produced by our Essay Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.

1. What is virtual machine allocation

Virtual machine provisioning can be very challenging within the realm of cloud computing, especially within the area of cloud allocation. With, each virtual machine assigned onto a host in compliance requested from the client on the host machine. (Ezugwu, Buhari and Junaidu, 2013), This means that the virtual machine is reliant on the resources of the physical machine, such as memory and storage, for the virtual machine to operate.

An example of the process used for the provision of the virtual machine is shown in figure 1.

Figure 1 – Virtual Machine provisioning (Hosts, 2018)

When a virtual machine is allocated, it will go through several stages. The first stage in the process is the request from the client/end-user including such information as virtual hardware requirements, the Operating System, and the amount of time the VM (Virtual Machine) is required for, also during the first stage a SLA (Service Level Agreement is agreed between client and host. Secondly, the request must go through an approval stage, either automatic or manual. Finally, the request is executed. This part of provisioning given the client access to the VM.

Since when a client submits a request for a VM, the cloud provider needs to have the ability resources to accommodate this, if does not would need to reject the order, this could be passed onto a cloud broker if the resources required outweigh the capacity of the cloud provider.

The SLA is an agreement between the cloud provider and the client, within the service level arrangement, there is a Service Level Objectives (SLO), these are the performance metrics that the cloud provider must meet in order to not breach the SLA between the cloud provider and the customer. Examples of SLO’s are: Bandwidth, network availability, and response time.

The SLA between the cloud provider and the client can either be informal or formal, if the SLA is formal, the SLA will usually be a formal document wrote into a contractual agreement which will contain the specification of each SLO. The document could also contain the penalty or fines for a breach in the agreed SLA between the cloud provider and the client. However, the SLA could be informal, in which there is no documents of the SLA. Regardless if the SLA is formal or unformal, the customers will expect a certain level of quality in the service provided to them. If a cloud provider fails to meet the SLA agreement, the provider could face damage to the company’s reputation, which would lead to a loss in profit for the cloud provider.

When it comes to the placement of the VM at the cloud provider great care is required, to help minimise power consumption since spinning up a host for each order if specification does not require 100% of the utilisation of the host, multiple VM can be ran on the same host, another factor this is a priority is the cloud provider has more than one data centre possible across Europe or world, since if client required low latency a putting the VM in a centre far away from the client this could greatly impact the end user experience and possible breach the SLA.

An example of this could be Host 1 is at 40% utilisation and has 3 years remaining contract time to fulfil, and host 2 at 50% utilisation and has 1 year remaining fulfil, and the new order requires 10% utilisation requiring 2-week contract, so all VM can be ran on the same host.

If more utilisation was required by the 10%/2 weeks contract, would need to spin up a second host, this can be done via live migration this allows the VM to be transferred to another host using such software as Vmotion, Azure Migrate, SCVMM depending on the infrastructure, since when using migration this would not breach the SLA since the VM is moved on the fly without the need to power down the VM and transfer to another host, since doing migration of the VM’s to different hosts can help lower the operational costs of the cloud provider.

2. Virtual machine allocation: Architecture and Process

2.1 Virtual Machine Allocation: Architecture

Within the virtual machines architecture comprises of many mechanisms, which can be divided into two main areas:

  • Front End – Refers to the customer/client facing, this consist of software that is required to access the cloud for example a web browser such as Internet Explorer or similar.
  • Back End – Refers to the cloud itself, it comprises a large data storage unit, security mechanism, services, deployments models, Policies, Monitoring, Virtual Machines and Servers.

An example of the front end and back end system is shown in figure 2.

Figure 2 – Front and Back End

2.1.1 Cloud Computing Monitoring

When implementing virtual machine, close monitoring is required to maximise efficacy and to bring down overhead costs, since having hosts running on idle with no assigned tasks would be a waste of power, there is many types of software that can monitor virtual machines such as solarWinds, Paessler and Veeam One (PC & Network Downloads – PCWDLD.com, 2018).  An example of the monitoring is shown decision flow in figure 3.

Figure 3 – Virtual Machine Monitor

Since with the monitoring, if a host is getting over utilised could perform migration of the virtual machines onto another host to ease the CPU, memory, and storage resources, additionally if the hosts is suffering any potential hardware failure all virtual machines could be transferred to another host, when using migration and the appropriate hardware/software is place a live migration is possible without the need to power down the virtual machine to complete the migration, or if there is limited resources the Virtual Machine could be relocated onto a different cloud provider as a temporary measure, but if was to transfer onto a different cloud provider this could possible impact on the SLA with the client/customer.

As previously stated monitoring of the overheads involved in cloud computing is vital at keeping costs down, the results of the monitoring would be feed back to the global manager, shown in figure 4.

Figure 4 – Monitoring Flow

2.1.2 Front and Backend Features  

Features like networking, storage, Servers, Virtualisation and security is managed by the cloud provider an example of who has control over features is shown in figure 5, features like security is extremely important since multiple virtual machines could be ran on the same host, since need to make sure only certain people have the correct access rights.

Figure 5 – Type of Service

2.2 Virtual Machine Allocation Process

To process of allocating Virtual Machines can be done in 8 stages shown in figure 6, this is done by taking the order from the client, this is passed onto the data centre with the appropriate hardware such as storage, processing capability, memory.

Figure 6 – VM Allocation Process

3. Overview on the methods of virtual machine allocation

The placement of virtual machines can be considered either static or dynamic placement:

  • Static VM Placement: This is where the virtual machine is fixed throughout the lifetime of the Virtual machine, and it will not be recomputed for a long period of time.
  • Dynamic VM placement: This is where the Virtual Machine is assigned to a certain host at the data centre, but can be changed or migrated to a different host depending on the system load.

Furthermore when implementing dynamic VM placement can be split into two sub-sections these being Reactive and Proactive, an example of the VM placement is shown in figure 7.

Figure 7 – VM Placement

A basic form of VM allocation, when a order comes into a is to be allocated to a Server within the data centre, multiple VM’s could be placed on Server1 with others being placed in Server2, this is shown in figure 8.

Figure 8 – VM to Server Placement

The Reactive VM Allocation maintains the performance of a computing system within required bounds by observing when the system’s performance is close to crossing, or has crossed, a threshold; if going over these limits determining how best to reallocate the available resources to prevent breaching the SLA agreed between the clients.

The Proactive Allocation maintains the routine of a computing system within required bounds by anticipating critical changes in the system state, pre-planning resource allocations appropriate to those changes, monitoring the system state for those changes, and implementing the appropriate pre-planned resource allocation when the system state changes.

An alternative view of the dynamic and static placement, is the use of power based and Application QOS Based placement of the VM’s, there is where high demand services like VoIP would be placed on the Application QOS based, where more intensive application would be ran on the power based servers, the figure 9 shows the different types of algorithms that could be implemented.

Figure 9 – Power/QOS Placement

A VM placement algorithm in cloud computing consists of two parts. First, a cloud should be found to host the VM and second, it must be determined which host of the selected cloud must host the VM. Thus, the VM placement in cloud computing. The objectives of an ideal VM placement can be listed as follows:

  • Reducing cloud traffic

○                    Decreasing VM to VM traffic

○                    Decreasing VM to storage(data) traffic

  • Preventing congestion in data centre’s network
  • Distributing traffic evenly in data centre’s network Mitigating energy consumption
  • Reducing cost for cloud providers and increasing the return on investment (ROI)
  • Increasing security
  • Maximizing resource utilisation
  • Improving Load balancing High performance
  • Locality: To increase accessibility, the VMs should be located close to the users, but this may not necessarily produce an optimal placement.
  • Reducing the number of active ports on (switches)
  • Minimizing the SLA violation: SLA is usually defined as the difference between the total MIPS requested by all the VMs from the total MIPS allocated to its VMs

High reliability and availability: To achieve these properties, the VMs may be placed, replicated or migrated across multiple geographical zones. During this procedure, factors such as the importance of the data/service encapsulated in the VMs, its expected usage frequency, and the reliability of the data centres must be considered.

Minimising the number of active servers: The energy consumption of a data centres is mainly caused by running VMs, thus VM placement schemes try to minimize the number of servers which are in use.

4. Contrasts and discussions on two major methods for virtual machine allocation

This section of report will contrast and discuss the differences and consequences of using Reactive and Proactive cloud computing allocation when implementing virtual machine allocation.

4.1 Reactive Allocation

In complex computational systems, no single allocation of resources to services is likely to be permanently optimal, or even acceptably effective. Hence resource allocation and reallocation will be required during system execution. The problem of reallocation involves determining that the system is failing to meet one or more critical performance requirements; adapting either the application load or resource assignment to improve the system’s performance; and accomplishing the reallocation without disrupting the system operation for an excessive period of time. Accomplishing these requires resolving the following:

  • The monitoring of system performance must impose a minimal overhead on the normal operation of the system; in particular, the benefit of reallocating resources must exceed the cost of monitoring.
  • The triggering and allocation determination functions must be either predictable or fast, and the reallocation function must be fast, in order to minimize the period of time during which system QoS constraints are violated.
  • The allocation determination function should be flexible, to allow for resource failures and for the installation of new resources.
  • The allocation determination function can be simplified and accelerated by restricting certain resources to support only specified services (“stovepiping”), but resource utilisation will likely be thereby decreased.
  • The combination of the triggering function with the allocation determination function must be stable, to ensure that after reallocation another reallocation will not be immediately initiated, which could lead to system collapse.
  • The allocation determination function must respect the criticalities of current allocations, such as TCP connections that must not be broken, or messages must not be lost.
  • The reallocation function must respect criticalities of on-going services (e.g. avoiding dropped messages).

These issues can be overcome by the use of monitoring as discussed in section 2.1.1 of this report, where multiple objects can be monitored looking at the systems behaviour, and if an issue is triggered the appropriate measures can be taken such as migration of the allocated VM.

4.1.1 Advantages and Disadvantages of Reactive Allocation

Reactive Resource Reallocation provides the following benefits:

  • The ability to gracefully maintain end-to-end qualities of service within specified bounds over a wide variety of load and failure conditions.
  • The ability to make effective use of reactive capabilities that are built into COTS components, such as routers.

However, the Reactive Resource Reallocation pattern encounters the following liability:

  • A long time may be required to react to a sudden change in service requirements
  • or infrastructure capabilities if the change invalidates a large proportion of the current resource allocations, or if the infrastructure is geographically dispersed.

4.2 Proactive Allocation

In long-lived, complex, computational systems, no single allocation of resources to services is likely to be permanently optimal, or even acceptably efficient. Hence resource allocation and reallocation will be required during system execution. However, in safety or mission critical systems timing constraints must be met to ensure the system behaves properly. This property typically eliminates dynamic adaptive reallocation (as defined in section 4.1) as a potential solution. Instead, specific critical “reallocation points” are identified in advance – these may include faults, mission changes, resources changes, system events, environmental changes. New system allocations are computed for each of these “reallocation points” prior to system operation. The computation of the solution is typically done during design or online as part of transitioning from one system allocation to another. In the latter case, the computation must be bounded in execution and must produce provably acceptable solutions. Accomplishing these requires resolving the following:

  • The monitoring of system performance must impose a minimal overhead on the normal operation of the system; in particular, the benefit of reallocating resources must exceed the cost of monitoring.
  • The allocation determination function must produce reallocations that are provably acceptable (meaning that they are correct and provide and acceptable level of performance).
  • The worst case execution time of the triggering and reallocation functions must be predictable and typically fast in order to minimize the period of time during which system QoS constraints are violated.

Proactive Resource Reallocation provides the following benefits:

The ability to provide specified end-to-end qualities of service quickly following an anticipated change in system state.

The ability to determine that specified qualities of service cannot be provided in advance of their need (and thereby to prevent a problem rather than responding to the problem).

However, the Proactive Resource Allocation pattern encounters the following

liabilities:

Not every mode change can be anticipated (e.g., multiple resource failures); hence support for some reactive resource reallocation is generally desirable.

6. References

  • Ezugwu, A., Buhari, S. and Junaidu, S. (2013). Virtual Machine Allocation in Cloud Computing Environment. International Journal of Cloud Applications and Computing, 3(2), pp.47-60.
  • Calheiros, N. R., Buyya, R., & De Rose, F. A. C. 2009. A heuristic for mapping virtual machines and links in emulation testbeds. In Proceedings of the 9th International Conference on Parallel Processing (ICPP) (pp. 518–525). Washington, DC: IEEE Computer Society.
  • Hosts, P. (2018). Provisioning Virtual Machines and Hosts – Red Hat Customer Portal. [online] Access.redhat.com. Available at: https://access.redhat.com/documentation/en-us/red_hat_cloudforms/4.0/html-single/provisioning_virtual_machines_and_hosts/index [Accessed 16 Dec. 2018].
  • PC & Network Downloads – PCWDLD.com. (2018). Best VM Manager for Monitoring Virtual Machines, ESXi and Hyper-V. [online] Available at: https://www.pcwdld.com/best-vm-manager-and-monitoring [Accessed 19 Dec. 2018].
  • RATHORE, S, International Journal of Computer Science and Informatics ISSN (PRINT): 2231 –5292, Volume-2, Issue-3, 2012

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please: