COMP 3000 Essay 2 2010 Question 10 - Revision history

Soma: Protected "COMP 3000 Essay 2 2010 Question 10" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-12-03T19:45:37Z

Protected "COMP 3000 Essay 2 2010 Question 10" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 19:45, 3 December 2010
(No difference)

Dagar: /* Background Concepts */

2010-12-03T11:40:31Z

Background Concepts

← Older revision		Revision as of 11:40, 3 December 2010
Line 21:		Line 21:
	'''Hypervisors''' are responsible for multiplexing hardware resources between virtual machines while providing isolation to an extent, using resource management. Three controls used by the hypervisor are: reservations, where the minimum bounds are set (in absolute units); limits, where the maximum upper bound on the allocation is set (again in absolute units); and shares, which proportionally allocate the resources according to the weight of each VM. These three controls have been supported for CPU and memory resource allocation since 2003. However, the current issue is I/O resource allocation. Currently, when more VMs are added to a host, the contention for input/output (I/O) resources can suddenly lower a VM’s allocation. Also, the available throughput can change with time, and adjustments to allocations must be made dynamically.		'''Hypervisors''' are responsible for multiplexing hardware resources between virtual machines while providing isolation to an extent, using resource management. Three controls used by the hypervisor are: reservations, where the minimum bounds are set (in absolute units); limits, where the maximum upper bound on the allocation is set (again in absolute units); and shares, which proportionally allocate the resources according to the weight of each VM. These three controls have been supported for CPU and memory resource allocation since 2003. However, the current issue is I/O resource allocation. Currently, when more VMs are added to a host, the contention for input/output (I/O) resources can suddenly lower a VM’s allocation. Also, the available throughput can change with time, and adjustments to allocations must be made dynamically.

	'''Throughput''' is the average rate of job completion. In general, a system is considered more efficient if it has a higher throughput <sup>[[#Foot6\|6]]</sup>. In this paper, this term is used to discuss the fact that throughput varies, and the number of jobs a system wishes to complete varies as well. Therefore it is necessary to take throughput into account when scheduling IO resources.		'''Throughput''' is the average rate of job completion. In general, a system is considered more efficient if it has a higher throughput <sup>[[#Foot6\|6]]</sup>. In this paper, this term is used to discuss the fact that throughput varies, and the number of jobs a system wishes to complete varies as well. Therefore it is necessary to take throughput into account when scheduling I/O resources.

	'''SFQ''', or Start-Time Fair Queuing, is the traditional scheduler currently used to allocate resources. It follows a proportional-sharing algorithm which divides up the total throughput between the VMs in proportion to their assigned shares. The issue with this is that it does not consider reservations or limits in its allocation.		'''SFQ''', or Start-Time Fair Queuing, is the traditional scheduler currently used to allocate resources. It follows a proportional-sharing algorithm which divides up the total throughput between the VMs in proportion to their assigned shares. The issue with this is that it does not consider reservations or limits in its allocation.

Dagar: /* Critique */

2010-12-03T11:36:53Z

Critique

← Older revision		Revision as of 11:36, 3 December 2010
Line 56:		Line 56:
	The paper proposes a better, and effective alternative to SFQ and other older methods and the mClock algorithm efficiently handles multiple VMs in a throughput environment (LUN, PARDA).		The paper proposes a better, and effective alternative to SFQ and other older methods and the mClock algorithm efficiently handles multiple VMs in a throughput environment (LUN, PARDA).

	The negative aspect of this paper was the writing style used for displaying calculations. In many sections of the essay, the calculations are embedded in a sentence which makes it difficult to read and understand ~~them~~. One example is the following line: "For a small reference I/O size of 8KB and using typical values for mechanical delay T<sub>m</sub> = 5ms and peak transfer rate, B<sub>peak</sub> = 60 MB/s, the numerator = Lat<sub>1</sub>*(1 + 8/300) ≈ Lat<sub>1</sub>" <sup>[[#Foot2\|2]]</sup>.<math></math> The calculations were often about how the algorithm would calculate the resource allocation but it was not really necessary to include them; the essay is understandable without them.		The negative aspect of this paper was the writing style used for displaying calculations. In many sections of the essay, the calculations are embedded in a sentence which makes them difficult to read and understand. One example is the following line: "For a small reference I/O size of 8KB and using typical values for mechanical delay T<sub>m</sub> = 5ms and peak transfer rate, B<sub>peak</sub> = 60 MB/s, the numerator = Lat<sub>1</sub>*(1 + 8/300) ≈ Lat<sub>1</sub>" <sup>[[#Foot2\|2]]</sup>.<math></math> The calculations were often about how the algorithm would calculate the resource allocation but it was not really necessary to include them; the essay is understandable without them.

	In general, however, the essay is clear and not difficult to understand. As well, the case for this algorithm appears well-presented and valid.		In general, however, the essay is clear and not difficult to understand. As well, the case for this algorithm appears well-presented and valid.

Dagar: /* Critique */

2010-12-03T11:34:39Z

Critique

← Older revision		Revision as of 11:34, 3 December 2010
Line 52:		Line 52:
	==Critique==		==Critique==

	The article introduces the mClock algorithm which handles I/O resource allocation on multiple VMs in a variable throughput environment. The Quality of Service (QoS) requirements for a VM are expressed as a minimum reservation, a maximum limit, and a proportional share. A positive aspect of this algorithm is that it is able to meet those controls in varying capacity. Also, it is significant that the algorithm was proven to be more efficient than existing methods at allocating IO resources in clustered architectures while providing greater isolation between VMs. mClock allows users to be comfortable when working with multiple VMs on one host without the constant worry of performance levels, with each VM add-on.		The article introduces the mClock algorithm which handles I/O resource allocation on multiple VMs in a variable throughput environment. The Quality of Service (QoS) requirements for a VM are expressed as a minimum reservation, a maximum limit, and a proportional share. A positive aspect of this algorithm is that it is able to meet those controls in varying capacity. Also, it is significant that the algorithm was proven to be more efficient than existing methods at allocating I/O resources in clustered architectures while providing greater isolation between VMs. mClock allows users to be comfortable when working with multiple VMs on one host without the constant worry of performance levels, with each VM add-on.

	The paper proposes a better, and effective alternative to SFQ and other older methods and the mClock algorithm efficiently handles multiple VMs in a throughput environment (LUN, PARDA).		The paper proposes a better, and effective alternative to SFQ and other older methods and the mClock algorithm efficiently handles multiple VMs in a throughput environment (LUN, PARDA).

Dagar: /* Contribution */

2010-12-03T11:32:12Z

Contribution

← Older revision		Revision as of 11:32, 3 December 2010
Line 48:		Line 48:
	mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve performance. The mClock algorithm should be relatively portable and easy to implement in other hypervisors.		mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve performance. The mClock algorithm should be relatively portable and easy to implement in other hypervisors.

	Another contribution was the introduction of Distributed mClock or '''dmClock''' which basically runs an altered version of mClock at each server. dmClock is mainly used for cluster-based storage system which are rising as centralized disk arrays, and better ~~than the alternatives~~ in terms of cost. The reservation in this modified algorithm gives higher preference to non-idle VMs to attain ~~high~~ performance. dmClock proved to be effective with a simple, modified mClock algorithm which does not require complex synchronizations between servers.		Another contribution was the introduction of Distributed mClock or '''dmClock''' which basically runs an altered version of mClock at each server. dmClock is mainly used for cluster-based storage system which are rising as an alternative to centralized disk arrays, and are better in terms of cost. The reservation in this modified algorithm gives higher preference to non-idle VMs to attain greater performance. dmClock proved to be effective with a simple, modified mClock algorithm which does not require complex synchronizations between servers.

	==Critique==		==Critique==

Dagar: /* Contribution */

2010-12-03T11:28:26Z

Contribution

← Older revision		Revision as of 11:28, 3 December 2010
Line 48:		Line 48:
	mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve performance. The mClock algorithm should be relatively portable and easy to implement in other hypervisors.		mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve performance. The mClock algorithm should be relatively portable and easy to implement in other hypervisors.

	Another contribution was the introduction of Distributed mClock or dmClock which basically runs an altered version of mClock at each server. dmClock is mainly used for cluster-based storage system which are rising as centralized disk arrays, and better than the ~~alternates~~ in terms of cost. The reservation in this modified algorithm gives higher preference to non-idle VMs to attain high performance. dmClock proved to be effective with a simple, modified mClock algorithm which does not require complex synchronizations between servers.		Another contribution was the introduction of Distributed mClock or '''dmClock''' which basically runs an altered version of mClock at each server. dmClock is mainly used for cluster-based storage system which are rising as centralized disk arrays, and better than the alternatives in terms of cost. The reservation in this modified algorithm gives higher preference to non-idle VMs to attain high performance. dmClock proved to be effective with a simple, modified mClock algorithm which does not require complex synchronizations between servers.

	==Critique==		==Critique==

Dagar: /* Contribution */

2010-12-03T11:27:07Z

Contribution

← Older revision		Revision as of 11:27, 3 December 2010
Line 44:		Line 44:
	mClock is a resource-allocation algorithm that helps hypervisors manage I/O requests from multiple virtual machines simultaneously. It is a better alternative to SFQ because it supports all controls in a single algorithm, handles variable and unknown capacity, and computes quickly. The algorithm does not weaken the performance level as each VM gets added on, and mClock reservations are met. Essentially, mClock dynamically adjusts the proportions of resources each VM receives based on current activity. While mClock constantly changes the physical resource allocation to each VM, it lets each VM hold onto the illusion that it has full control of all system resources. As a result, performance can be increased for VMs that need it, without letting the others know that “their” resources are being distributed to other machines. What mClock attempts to achieve is combining a constraint-based scheduler and a weight-based scheduler. Making sure the minimum I/O reservation limit is consistently met, yet not over the upper bound limit, would be handled by the constraint-based scheduler. Then, it is the responsibility of the weight-based scheduler to distribute the remaining I/O throughput to the rest of the VMs equally.		mClock is a resource-allocation algorithm that helps hypervisors manage I/O requests from multiple virtual machines simultaneously. It is a better alternative to SFQ because it supports all controls in a single algorithm, handles variable and unknown capacity, and computes quickly. The algorithm does not weaken the performance level as each VM gets added on, and mClock reservations are met. Essentially, mClock dynamically adjusts the proportions of resources each VM receives based on current activity. While mClock constantly changes the physical resource allocation to each VM, it lets each VM hold onto the illusion that it has full control of all system resources. As a result, performance can be increased for VMs that need it, without letting the others know that “their” resources are being distributed to other machines. What mClock attempts to achieve is combining a constraint-based scheduler and a weight-based scheduler. Making sure the minimum I/O reservation limit is consistently met, yet not over the upper bound limit, would be handled by the constraint-based scheduler. Then, it is the responsibility of the weight-based scheduler to distribute the remaining I/O throughput to the rest of the VMs equally.

	The mClock algorithm uses a tag-based scheduler with some modifications; like ~~the~~ tag-based schedulers all I/O requests are assigned tags and scheduled in order of their tag values~~, the~~ modifications ~~includes~~ the ability to use multiple tags based on the three controls and to dynamically decide which tag to use for scheduling, while still synchronizing idle VMs <sup>[[#Foot2\|2]]</sup>.		The mClock algorithm uses a tag-based scheduler with some modifications; like other tag-based schedulers all I/O requests are assigned tags and scheduled in order of their tag values. The modifications include the ability to use multiple tags based on the three controls (shares, reservations and limits) and to dynamically decide which tag to use for scheduling, while still synchronizing idle VMs <sup>[[#Foot2\|2]]</sup>.

	mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve ~~its~~ performance ~~results~~. ~~Therefore,~~ mClock ~~would~~ be portable and easy to implement in other hypervisors ~~as well~~.		mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve performance. The mClock algorithm should be relatively portable and easy to implement in other hypervisors.

	Another contribution was the introduction of Distributed mClock or dmClock which basically runs an altered version of mClock at each server. dmClock is mainly used for cluster-based storage system which are rising as centralized disk arrays, and better than the alternates in terms of cost. The reservation in this modified algorithm gives higher preference to non-idle VMs to attain high performance. dmClock proved to be effective with a simple, modified mClock algorithm which does not require complex synchronizations between servers.		Another contribution was the introduction of Distributed mClock or dmClock which basically runs an altered version of mClock at each server. dmClock is mainly used for cluster-based storage system which are rising as centralized disk arrays, and better than the alternates in terms of cost. The reservation in this modified algorithm gives higher preference to non-idle VMs to attain high performance. dmClock proved to be effective with a simple, modified mClock algorithm which does not require complex synchronizations between servers.

Dagar: /* Contribution */

2010-12-03T11:23:16Z

Contribution

← Older revision		Revision as of 11:23, 3 December 2010
Line 42:		Line 42:
	Older methods of I/O resource allocation had a significant performance disadvantage. Whenever the load on the shared storage device was increased, or when another VM was added, the performance of all hosts would drop significantly. Also, these older methods provided unreliable I/O management of hypervisors. Conversely, mClock is able to present VMs with a guaranteed minimum reservation of I/O resources. This means that application performance will never drop below a certain point. This provides much better application stability on each of the VMs, and better overall performance and efficiency level, compared to older methods such as SFQ.		Older methods of I/O resource allocation had a significant performance disadvantage. Whenever the load on the shared storage device was increased, or when another VM was added, the performance of all hosts would drop significantly. Also, these older methods provided unreliable I/O management of hypervisors. Conversely, mClock is able to present VMs with a guaranteed minimum reservation of I/O resources. This means that application performance will never drop below a certain point. This provides much better application stability on each of the VMs, and better overall performance and efficiency level, compared to older methods such as SFQ.

	mClock is a resource-allocation algorithm that helps hypervisors manage I/O requests from multiple virtual machines simultaneously. It is a better alternative to SFQ because it supports all controls in a single algorithm, handles variable and unknown capacity, and computes quickly. The algorithm does not weaken the performance level as each VM gets added on, and mClock reservations are met. Essentially, mClock dynamically adjusts the proportions of resources each VM receives based on ~~how active each VM currently is~~. While mClock constantly changes the physical resource allocation to each VM, it lets each VM hold onto the illusion that it has full control of all system resources. As a result, performance can be increased for VMs that need it, without letting the others know that “their” resources are being distributed to other machines. What mClock attempts to achieve is combining a constraint-based scheduler and a weight-based scheduler. Making sure the minimum IO reservation limit is consistently met, yet not over the upper bound limit, would be handled by the constraint-based scheduler. Then, it is the responsibility of the weight-based scheduler to distribute the remaining IO throughput to the rest of the VMs equally.		mClock is a resource-allocation algorithm that helps hypervisors manage I/O requests from multiple virtual machines simultaneously. It is a better alternative to SFQ because it supports all controls in a single algorithm, handles variable and unknown capacity, and computes quickly. The algorithm does not weaken the performance level as each VM gets added on, and mClock reservations are met. Essentially, mClock dynamically adjusts the proportions of resources each VM receives based on current activity. While mClock constantly changes the physical resource allocation to each VM, it lets each VM hold onto the illusion that it has full control of all system resources. As a result, performance can be increased for VMs that need it, without letting the others know that “their” resources are being distributed to other machines. What mClock attempts to achieve is combining a constraint-based scheduler and a weight-based scheduler. Making sure the minimum I/O reservation limit is consistently met, yet not over the upper bound limit, would be handled by the constraint-based scheduler. Then, it is the responsibility of the weight-based scheduler to distribute the remaining I/O throughput to the rest of the VMs equally.

	The mClock algorithm uses a tag-based scheduler with some modifications; like the tag-based schedulers all I/O requests are assigned tags and scheduled in order of their tag values, the modifications includes the ability to use multiple tags based on the three controls and to dynamically decide which tag to use for scheduling, while still synchronizing idle VMs <sup>[[#Foot2\|2]]</sup>.		The mClock algorithm uses a tag-based scheduler with some modifications; like the tag-based schedulers all I/O requests are assigned tags and scheduled in order of their tag values, the modifications includes the ability to use multiple tags based on the three controls and to dynamically decide which tag to use for scheduling, while still synchronizing idle VMs <sup>[[#Foot2\|2]]</sup>.

	mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve its performance results. Therefore, mClock would be portable and easy to implement in other hypervisors as well.		mClock was implemented on a modified version of VMware ESX server hypervisor <sup>[[#Foot4\|4]]</sup> <sup>[[#Foot5\|5]]</sup>. This modification only took around 200 lines of C code. This shows that it was not very difficult to implement mClock effectively in a existing product, and to improve its performance results. Therefore, mClock would be portable and easy to implement in other hypervisors as well.

Naseido: /* Problem*/

2010-12-03T11:19:18Z

Problem

← Older revision		Revision as of 11:19, 3 December 2010
Line 27:		Line 27:
	==Research problem==		==Research problem==

	====Problem ~~Facing~~====		====Problem====
	Today, I/O resource allocation in modern hypervisors is very simple and somewhat primitive. Currently, an algorithm called PARDA (Proportional Allocation of Resources in Distributed storage Access) <sup>[[#Foot1\|1]]</sup> is used to allocate I/O resources to each VM running on a particular storage device. Unfortunately, the I/O resource allocation algorithm of the hosts use a fair-scheduler called SFQ <sup>[[#Foot2\|2]]</sup> <sup>[[#Foot3\|3]]</sup>.SFQ(D) (Start-time Fair Queuing) performs fairly well for low-intensity workloads. However, as the workload with VMs multiplies, the constant need for faster performance and efficiency rises.		Today, I/O resource allocation in modern hypervisors is very simple and somewhat primitive. Currently, an algorithm called PARDA (Proportional Allocation of Resources in Distributed storage Access) <sup>[[#Foot1\|1]]</sup> is used to allocate I/O resources to each VM running on a particular storage device. Unfortunately, the I/O resource allocation algorithm of the hosts use a fair-scheduler called SFQ <sup>[[#Foot2\|2]]</sup> <sup>[[#Foot3\|3]]</sup>.SFQ(D) (Start-time Fair Queuing) performs fairly well for low-intensity workloads. However, as the workload with VMs multiplies, the constant need for faster performance and efficiency rises.

Naseido: /* Background Concepts */

2010-12-03T11:18:50Z

Background Concepts

← Older revision		Revision as of 11:18, 3 December 2010
Line 24:		Line 24:

	'''SFQ''', or Start-Time Fair Queuing, is the traditional scheduler currently used to allocate resources. It follows a proportional-sharing algorithm which divides up the total throughput between the VMs in proportion to their assigned shares. The issue with this is that it does not consider reservations or limits in its allocation.		'''SFQ''', or Start-Time Fair Queuing, is the traditional scheduler currently used to allocate resources. It follows a proportional-sharing algorithm which divides up the total throughput between the VMs in proportion to their assigned shares. The issue with this is that it does not consider reservations or limits in its allocation.

	SFQ(D) (Start-time Fair Queuing)<sup>[[#Foot2\|2]]</sup> <sup>[[#Foot3\|3]]</sup> performs fairly well for low-intensity workloads. However, as the workload with VMs multiplies, the constant need for faster performance and efficiency rises. Hypervisors require a better resource-allocation algorithm in order to meet the need for high performance VMs running concurrently; mClock was the answer Gulati, Varman, and Merchant proposed.

	==Research problem==		==Research problem==