why virtualization?
11 views
Skip to first unread message
Dan Kearns
Dec 17, 2008, 12:05:31 PM12/17/08
to cloud-c...@googlegroups.com
Out of curiosity.... it seems to me that two pretty fundamental tenets of cloud computing are contradictory:
Virtualization: a mechanism to get better utilization of existing hardware when loads are generally smaller than node capacity, or spiky in the time domain
Griddiness: (for lack of a better word) the idea that appropriate cloud designs support massive scale, and do it by aggregating many small+cheap failure-prone compute units with smarter software
If the goals are to have smarter software and maximize utilization (or minimize power consumption for equivalent compute capacity), then why introduce the constant runtime overhead of virtualization instead of, eg using smaller more power-efficient compute-unit designs and making the hardware controllable by software?
Am I missing something, or is virtualization a tactical answer and therefore a short-term solution, and not a great place to start building management frameworks (for example) on top of?
-d
Krishna Sankar (ksankar)
Dec 17, 2008, 1:12:49 PM12/17/08
to cloud-c...@googlegroups.com
Dan,
Good line of thought. Couple of points:
a) Power efficiency – I think an 8 core machine (with 7.5 VM processes) would use less power than 8 small machines (say powered by via itx). But if one is using only one VM and one process, then the rest of the power is wasted
b) Yes, from an enterprise IT application infrastructure perspective, virtualization s a short term solution with a cloud infrastructure as the long term goal
c) Virtualization in some sense is getting more granularity than a hardware box (for better utilization) and that would eventually shift to the infrastructure providers
d) BTW, IMHO, elasticity was never the goal of virtualization not can we achieve elasticity by virtualization – they are orthogonal
e) Same goes with scale and ad-hocness
f) And as you point out, virtualization has serious drawbacks – like multi-core and extra overhead.
Cheers & happy holidays
<k/>
Boris K
Dec 17, 2008, 1:28:51 PM12/17/08
to cloud-c...@googlegroups.com
Dan,
It is an interesting observation. Let me try to reconcile the two tenets.
If we look at this problem from 'bin packing' point of view, both tenets seem to complement each other.
Bin packing problem is an old operations research problem about packing several bins of known volumes with multiple smaller (by Volume) objects. To apply this model to the grid world: let us think of grid nodes as bins above, let us interpret bin volume as computational capacity of a node, let us think that computational tasks/applications are the objects with which we pack the bins(nodes).
Then this 'bin packing view' of grid computing becomes: how to allocate multiple computational tasks to several nodes in a near-optimal way (given certain constraints). This problem is NP complete, so we can strive only for near optimal allocation. The closeness to optimum is dependent on the size of the tasks: the smaller they are the better (more densely) we can pack the cluster.
So, having smaller virtualized tasks (tenet 1) allows us to get better overall optimization (aggregation is your terms) (tenet 2).
Boris
--- On Wed, 12/17/08, Dan Kearns <dan.k...@gmail.com> wrote:
Tarry Singh
Dec 17, 2008, 1:35:24 PM12/17/08
to cloud-c...@googlegroups.com
I can give you a long one or a short one there, Dan
So a short one is: Virtualization is a transition phase and the ones who are banking up too many hopes must realize that virtualization is a lot more than the hypervisor. many of my peers get stuck with customers on the table with the "we gotta bring your server count down!" whiel the whole ball game is ought to be:" we will help you scale up so you can keep incresing your productivity with decreasing costs". You can't say most of those things when you work for a little of big virtualizatino firm, cos you have to sell their piece of software or management software.
Seeing this VMware is beginning to wake up and starting to collaborate with HP etc to start managing all the layers. They have realized, much as others like MSFT who will also not work their asses off for their Hyper-V product, so I hear, that its 5% of global server markets that may be virtualized and by 2010 it might not go up dramatically. Cloud Computing is bound to address that dilemma by "We don't give a damn, just run it on our array, cos we know that you don't give a damn either"
And building management stuff adds only more complexity and thickens that whole layer. I think that is another thing many investors need to watch out for. There will be too much stuff and when the economy starts to heal at some point in time, it might still be wise to keep those itchy fingers in your pockets and wait for the Cloud. This I am saying while I strongly believe that virtualization is needed and you must choose wisely and keep "heterogeneity, interoperability using standards such as OVF, DMTF etc" so that when its time to move to the Cloud, you should just do it. Why? Commoditization and delevereging of your software stack is bound to continue through 2010-2011, meaning that you will be also evaluating and dumping the toxic shelfware software for some unified, converged sitapp that lives in the SIGnatured* cloud.
P.S: Deep down in our hearts we all know that the stuff that runs on raw iron, is better than the stuff that runs on stuff that runs on raw iron. Eventually I dream of some metal that fulfills all our needs in multiple forms while processing the meta-info directly on top of that metal/stuff.
* I am working on a GRCSER framework that I intend to share with some EU leaders soon.
Tarry--
Kind Regards,
Tarry Singh
______________________________________________________________
Founder, Avastu: Research-Analysis-Ideation
"Do something with your ideas!"
http://www.avastu.com
Business Cell: +31630617633
Private Cell: +31629159400
LinkedIn: http://www.linkedin.com/in/tarrysingh
Blogs: http://www.ideationcloud.com
So a short one is: Virtualization is a transition phase and the ones who are banking up too many hopes must realize that virtualization is a lot more than the hypervisor. many of my peers get stuck with customers on the table with the "we gotta bring your server count down!" whiel the whole ball game is ought to be:" we will help you scale up so you can keep incresing your productivity with decreasing costs". You can't say most of those things when you work for a little of big virtualizatino firm, cos you have to sell their piece of software or management software.
Seeing this VMware is beginning to wake up and starting to collaborate with HP etc to start managing all the layers. They have realized, much as others like MSFT who will also not work their asses off for their Hyper-V product, so I hear, that its 5% of global server markets that may be virtualized and by 2010 it might not go up dramatically. Cloud Computing is bound to address that dilemma by "We don't give a damn, just run it on our array, cos we know that you don't give a damn either"
And building management stuff adds only more complexity and thickens that whole layer. I think that is another thing many investors need to watch out for. There will be too much stuff and when the economy starts to heal at some point in time, it might still be wise to keep those itchy fingers in your pockets and wait for the Cloud. This I am saying while I strongly believe that virtualization is needed and you must choose wisely and keep "heterogeneity, interoperability using standards such as OVF, DMTF etc" so that when its time to move to the Cloud, you should just do it. Why? Commoditization and delevereging of your software stack is bound to continue through 2010-2011, meaning that you will be also evaluating and dumping the toxic shelfware software for some unified, converged sitapp that lives in the SIGnatured* cloud.
P.S: Deep down in our hearts we all know that the stuff that runs on raw iron, is better than the stuff that runs on stuff that runs on raw iron. Eventually I dream of some metal that fulfills all our needs in multiple forms while processing the meta-info directly on top of that metal/stuff.
* I am working on a GRCSER framework that I intend to share with some EU leaders soon.
Tarry
Kind Regards,
Tarry Singh
______________________________________________________________
Founder, Avastu: Research-Analysis-Ideation
"Do something with your ideas!"
http://www.avastu.com
Business Cell: +31630617633
Private Cell: +31629159400
LinkedIn: http://www.linkedin.com/in/tarrysingh
Blogs: http://www.ideationcloud.com
Niels Goldstein
Dec 17, 2008, 1:37:54 PM12/17/08
to cloud-c...@googlegroups.com
Dan,
Let me see if I can address this.
Virtualization is a means to disconnect the running application from the underlying hardware. Its an enabling technology used by all the cloud computing vendors to provide higher availability, mobility, and scalability.
How does it do that? Well, for one, virtualization disconnects the cycles of application development and deployment from hardware refresh. You can move a VM from one hardware platform to another without redesigning the application. I have a customer who recently replaced aging pizza box servers with blades, and since I had them move their apps to VMs, it was easy. Change the server controller to specify the old hardware was no longer available, specify that the new hardware was, and let the server controller move the VM to the new hardware either by live migrate or at next scheduled outage for patching. That very same process works to increase availability. Because when a piece of hardware fails, the server controller moves the VMs from the failed hardware to the replacement. Or, finds existing servers with capacity and shuffles VMs about to reach an optimum performance distribution.
Virtualization also provides scalability if you design your software load to allow for VM cloning. Simply clone a running VM, and start say, a new middle tier to take the load off the other(s).
And further, the choice of hardware is not necessarily to select the smallest available computing units, its to select the units that have the best price to capacity ratio, while not selecting hardware so big that a single unit failure takes out more than can be spread about the remaining hardware.
We select servers based upon cost of CPU to Ram to Power and Space ratio. And that changes over time. Virtualization also gives us the freedom to select hardware at todays prices, and not feel locked into one vendor.
Now, as for the connection between VMs and Cloud, its a logical step. Once your organization is comfortable with VMs, you can then pick those VMs up out of your data center, and run them on most cloud computing vendor's clouds. Same concept applies. So say your data center is currently at max capacity, and there is no better hardware to gain CPU to RAM to Power and space ratio, why not pick some of your lower, less mission critical services and simply run them in the CLOUD while technology and your facilities catch up? Overflow parking at the mall at Christmas analogy...
Once you can factor in your real cost of compute unit in your owned data center, you can then compare that to the vendors out there and see if it makes financial sense to engage for more and more, rather than building your own capacity. And if you're worried about the cloud vendor raising prices, just realize that if you've gone down this path, and have developed the in-house ability to manage VMs, you can always acquire co-lo space, or build out your own data center to compete with the cloud vendor.
Eventually, the actual cost of compute units will trend towards 4 underlying costs: The cost of low-skilled Labor to rack and stack, monitor and pull dead hardware, the cost for Electricity, the cost for Real Estate, and the cost for Hardware. If the cloud vendors mark that up too high, its then cheaper for their customers to run things themselves, and they lose competitive advantage.
A server controller with the ability to power on and off servers on-demand, with the ability to load balance VMs on the fly, and to move things from failed or failing hardware, and staff trained to develop and support VMs are the critical needs in this environment.
I hope that addresses what you need. Cloud does not replace or supplant Virtualiztion, used properly, it builds upon it. I recommend that you build your management framework on it as it translates into greater organizational efficiency.
Niels
Dan Kearns wrote:
Let me see if I can address this.
Virtualization is a means to disconnect the running application from the underlying hardware. Its an enabling technology used by all the cloud computing vendors to provide higher availability, mobility, and scalability.
How does it do that? Well, for one, virtualization disconnects the cycles of application development and deployment from hardware refresh. You can move a VM from one hardware platform to another without redesigning the application. I have a customer who recently replaced aging pizza box servers with blades, and since I had them move their apps to VMs, it was easy. Change the server controller to specify the old hardware was no longer available, specify that the new hardware was, and let the server controller move the VM to the new hardware either by live migrate or at next scheduled outage for patching. That very same process works to increase availability. Because when a piece of hardware fails, the server controller moves the VMs from the failed hardware to the replacement. Or, finds existing servers with capacity and shuffles VMs about to reach an optimum performance distribution.
Virtualization also provides scalability if you design your software load to allow for VM cloning. Simply clone a running VM, and start say, a new middle tier to take the load off the other(s).
And further, the choice of hardware is not necessarily to select the smallest available computing units, its to select the units that have the best price to capacity ratio, while not selecting hardware so big that a single unit failure takes out more than can be spread about the remaining hardware.
We select servers based upon cost of CPU to Ram to Power and Space ratio. And that changes over time. Virtualization also gives us the freedom to select hardware at todays prices, and not feel locked into one vendor.
Now, as for the connection between VMs and Cloud, its a logical step. Once your organization is comfortable with VMs, you can then pick those VMs up out of your data center, and run them on most cloud computing vendor's clouds. Same concept applies. So say your data center is currently at max capacity, and there is no better hardware to gain CPU to RAM to Power and space ratio, why not pick some of your lower, less mission critical services and simply run them in the CLOUD while technology and your facilities catch up? Overflow parking at the mall at Christmas analogy...
Once you can factor in your real cost of compute unit in your owned data center, you can then compare that to the vendors out there and see if it makes financial sense to engage for more and more, rather than building your own capacity. And if you're worried about the cloud vendor raising prices, just realize that if you've gone down this path, and have developed the in-house ability to manage VMs, you can always acquire co-lo space, or build out your own data center to compete with the cloud vendor.
Eventually, the actual cost of compute units will trend towards 4 underlying costs: The cost of low-skilled Labor to rack and stack, monitor and pull dead hardware, the cost for Electricity, the cost for Real Estate, and the cost for Hardware. If the cloud vendors mark that up too high, its then cheaper for their customers to run things themselves, and they lose competitive advantage.
A server controller with the ability to power on and off servers on-demand, with the ability to load balance VMs on the fly, and to move things from failed or failing hardware, and staff trained to develop and support VMs are the critical needs in this environment.
I hope that addresses what you need. Cloud does not replace or supplant Virtualiztion, used properly, it builds upon it. I recommend that you build your management framework on it as it translates into greater organizational efficiency.
Niels
Dan Kearns wrote:
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to
cloud-computi...@googlegroups.com
To post job listing, send email to jo...@cloudjobs.net (position title, employer and location in subject, description in message body) or visit http://www.cloudjobs.net
To submit your resume for cloud computing job bank, send it to res...@cloudjobs.net.
For more options, visit this group at
http://groups.google.ca/group/cloud-computing?hl=en?hl=en
Posting guidelines:
http://groups.google.ca/group/cloud-computing/web/frequently-asked-qu...
This group posts are licensed under a Creative Commons Attribution-Share Alike 3.0 United States License http://creativecommons.org/licenses/by-sa/3.0/us/
Group Members Meet up Calendar - http://groups.google.ca/group/cloud-computing/web/meet-up-calendar
-~----------~----~----~----~------~----~------~--~---
--
Niels Goldstein | Technical Director | Data Center and Infrastructure Management Center of Excellence Lead
Phone: +1 443 562 6198 | Fax: +1 443 364 4020 | Mobile: +1 443 562 6198
Oracle National Security Group (NSG)
7115 Bridoon Ave | Sykesville, MD 21784
Oracle is committed to developing practices and products that
help protect the environment
Niels Goldstein | Technical Director | Data Center and Infrastructure Management Center of Excellence Lead
Phone: +1 443 562 6198 | Fax: +1 443 364 4020 | Mobile: +1 443 562 6198
Oracle National Security Group (NSG)
7115 Bridoon Ave | Sykesville, MD 21784
Oracle is committed to developing practices and products that
help protect the environment
Christien Rioux
Dec 17, 2008, 1:45:57 PM12/17/08
to cloud-c...@googlegroups.com
> So a short one is: Virtualization is a transition phase
So, do we expect Google to take 'Native Client' and make 'Native
Cloud' out of it once we're done beta testing it for them?
--chris
gaberger
Dec 17, 2008, 2:02:54 PM12/17/08
to cloud-c...@googlegroups.com
I agree with Krishna and Dan,
I spin it in this way:
Virtualization – a.k.a Hypervisor, VMM – is used to decouple the OS from the hardware using both native drivers as well as partially-accelerated (VT-X) access to underlying hardware resources. This provides a consistent interface to hardware sub-structure allowing for “easier” tolerance for heterogeneity and as a byproduct allows OS instances to be highly portable (as long as the layer 2 connectivity is there).
So your point is correct, we will see this technology replace or evolve the OS kernel (i.e. VMWARE DCOS, Qumarant KVM) but the overhead thanks to hardware acceleration (I/OAT, EPT) will decrease to something like 5% (Intel source) which is negligible.. This is accomplished by allowing the Guest to run in Ring 0 of the processor and have more kernel-like permissions to access important memory structures such as the page table..
Griddiness – a.k.a Parallel Computing, Cloud, HPC and now what I think Forrester Research refers to as Ultra Modular Computing (UMC). This trends momentum is on using hundreds of (commodity) servers which represent an ecosystem which is linearly scalable, asynchronously persistent and self-modulating (Up, Down, Left, Right) depending on the SLA of the workload. Since it is built to large scale you have solved some of the heterogeneity and now can take advantage of the mobility of OS instances through things like Intel's Live Migration.
The piece that needs to change is the software architecture which needs to be capable of leveraging the increasing core counts as most traditional applications were never designed to be multi-threaded.
The next step will decouple the application from the OS and give us true scalability and it is being built on Space Based Architecture platforms such as Gigaspaces.
Cheers as well, Have a great holiday....
-g
I spin it in this way:
Virtualization – a.k.a Hypervisor, VMM – is used to decouple the OS from the hardware using both native drivers as well as partially-accelerated (VT-X) access to underlying hardware resources. This provides a consistent interface to hardware sub-structure allowing for “easier” tolerance for heterogeneity and as a byproduct allows OS instances to be highly portable (as long as the layer 2 connectivity is there).
So your point is correct, we will see this technology replace or evolve the OS kernel (i.e. VMWARE DCOS, Qumarant KVM) but the overhead thanks to hardware acceleration (I/OAT, EPT) will decrease to something like 5% (Intel source) which is negligible.. This is accomplished by allowing the Guest to run in Ring 0 of the processor and have more kernel-like permissions to access important memory structures such as the page table..
Griddiness – a.k.a Parallel Computing, Cloud, HPC and now what I think Forrester Research refers to as Ultra Modular Computing (UMC). This trends momentum is on using hundreds of (commodity) servers which represent an ecosystem which is linearly scalable, asynchronously persistent and self-modulating (Up, Down, Left, Right) depending on the SLA of the workload. Since it is built to large scale you have solved some of the heterogeneity and now can take advantage of the mobility of OS instances through things like Intel's Live Migration.
The piece that needs to change is the software architecture which needs to be capable of leveraging the increasing core counts as most traditional applications were never designed to be multi-threaded.
The next step will decouple the application from the OS and give us true scalability and it is being built on Space Based Architecture platforms such as Gigaspaces.
Cheers as well, Have a great holiday....
-g
--
Mike Patterson
Dec 17, 2008, 2:13:04 PM12/17/08
to cloud-c...@googlegroups.com
in my opinion...a short term transition..&..if your revenue generating App aren't on the cloud in a couple of years...they will not be relevant
Michael Patterson
CEO-StrongTech
www.ezasset.com
www.strongtech.com
614-329-8025
Michael Patterson
CEO-StrongTech
www.ezasset.com
www.strongtech.com
614-329-8025
Tarry Singh
Dec 17, 2008, 2:21:21 PM12/17/08
to cloud-c...@googlegroups.com
@gaberger
I hope you are saying what I am trying to comprehend here, you mean literally run in Ring 0?
Tarry
This is accomplished by allowing the Guest to run in Ring 0 of the processor
Tarry
Dan Kearns
Dec 17, 2008, 2:31:28 PM12/17/08
to cloud-c...@googlegroups.com
On Wed, Dec 17, 2008 at 10:37 AM, Niels Goldstein <niels.g...@oracle.com> wrote:
Virtualization is a means to disconnect the running application from the underlying hardware. Its an enabling technology used by all the cloud computing
...etc
We select servers based upon cost of CPU to Ram to Power and Space ratio. And that changes over time. Virtualization also gives us the freedom to select hardware at todays prices, and not feel locked into one vendor.
So I buy some of these arguments, but by no means all. If you believe folks like James Hamilton, datacenter buildout at scale means you can reevaluate almost all your hardware assumptions without adding significant cost to the buildout, and with the potential of oom-sized operational benefits. It's hard for me to believe that current enterprise-focused hardware (eg blade servers, big sun or ibm boxes, etc) are what you'd choose.
Virtualization (assumed to mean os virtualization) clearly can ease operational cost for a legacy application stack, but it is a pretty blunt instrument to apply to things like workload management - you're essentially maximizing the size of your movable state, introducing an incredibly coarse-grained locking infrastructure, and adding considerable management complexity (eg blowing out your spanning trees just to preserve the mac you had, because the os doesn't expect that to change in a single tick) in exchange for preserving your current architecture. That's more than just a 5% runtime penalty.
I'm wondering if at some point "the cloud" bifurcates into a space optimized for serving legacy stacks, and another optimized for more modern designs? If the latter, I'm wondering if the dominant abstraction is lower-level (think context switching, cache-line management, etc), or higher-level (think whatever griddy APIs you prefer).
Or maybe, if the vibe I'm getting here is on-target, advances in the lower and higher-level approaches will have to be complementary. ie building an arbitrarily complex software stack is "free" as long as it can a) then be stamped out at massive scale, and b) address the levels of granularity in workload management, and ease-of-consumption issues which hardware advances alone cannot.
Krishna, as I'm totally ignorant on multi-core designs - is the primary power-saving benefit purely a packaging issue, eg sharing a power line amongst the cores vs adding a whole additional "card", or is it a more integrated thing where there are dynamic runtime benefits derived from shared componentry? ie if I have an 8-core cpu in a huge datacenter buildout, is it equivalent to expose that thing as if it were 8 separate "computers" vs one 8-cpu "computer"?
-d
Jan Klincewicz
Dec 17, 2008, 2:52:02 PM12/17/08
to cloud-c...@googlegroups.com
Virtualization is a lot more than consolidation and resource utilization. It abstracts the OS and workload from physical hardware, reducing a very complex component to a file or two ..--
Cheers,
Jan
Cheers,
Jan
Utpal Datta
Dec 17, 2008, 3:00:30 PM12/17/08
to cloud-c...@googlegroups.com
>> BTW, IMHO, elasticity was never the goal of virtualization not can we achieve elasticity by virtualization – they are orthogonal
As far as we know, Amazon is based on a Xen infrastructure (i.e. virtualization). How are they achieving elasticity and scalability?
--utpal
gaberger
Dec 17, 2008, 3:32:54 PM12/17/08
to cloud-c...@googlegroups.com
On 12/17/08 2:31 PM, "Dan Kearns" <dan.k...@gmail.com> wrote:
On Wed, Dec 17, 2008 at 10:37 AM, Niels Goldstein <niels.g...@oracle.com> wrote:
...etc
Virtualization is a means to disconnect the running application from the underlying hardware. Its an enabling technology used by all the cloud computing
We select servers based upon cost of CPU to Ram to Power and Space ratio. And that changes over time. Virtualization also gives us the freedom to select hardware at todays prices, and not feel locked into one vendor.
So I buy some of these arguments, but by no means all. If you believe folks like James Hamilton, datacenter buildout at scale means you can reevaluate almost all your hardware assumptions without adding significant cost to the buildout, and with the potential of oom-sized operational benefits. It's hard for me to believe that current enterprise-focused hardware (eg blade servers, big sun or ibm boxes, etc) are what you'd choose.
gb >> “Commodity” server basically means x86. We are leveraging the open nature of the Intel x86 instruction set across many systems and abstracting the differences through OS virtualization. Ultimately you want zero variation.
Virtualization (assumed to mean os virtualization) clearly can ease operational cost for a legacy application stack, but it is a pretty blunt instrument to apply to things like workload management - you're essentially maximizing the size of your movable state, introducing an incredibly coarse-grained locking infrastructure, and adding considerable management complexity (eg blowing out your spanning trees just to preserve the mac you had, because the os doesn't expect that to change in a single tick) in exchange for preserving your current architecture. That's more than just a 5% runtime penalty.
gb>> Workload management is all the VMM does. It manages the memory space and schedules itself across available cores (XEN a little more configurable) as efficiently as possible as most applications are not designed very well to be multi-processer/multi-threaded application. That drives the CPU utilization higher allowing for a more efficient data center. The operational costs are not so linear as reducing 10K physical servers to 5K still requires management of 10K instances, but the upside is some of the energy savings but no where compares to the cost of a data center most enterprises are growing out of....
gb>>Large scale enterprises are already spanning geographies at layer 2, with the adoption of Data Center Bridging and L2MP we will eliminate spanning tree and scale to larger L2 domains. Other technologies like TRILL are on the way to the data center as well. We don’t need to hang on to the MAC but my point about the overhead was in runtime as you point out, during a VM movement state does have to be migrated and instructions queued, for the benefit of running less than Nx2 for redundancy.
I'm wondering if at some point "the cloud" bifurcates into a space optimized for serving legacy stacks, and another optimized for more modern designs? If the latter, I'm wondering if the dominant abstraction is lower-level (think context switching, cache-line management, etc), or higher-level (think whatever griddy APIs you prefer).
Or maybe, if the vibe I'm getting here is on-target, advances in the lower and higher-level approaches will have to be complementary. ie building an arbitrarily complex software stack is "free" as long as it can a) then be stamped out at massive scale, and b) address the levels of granularity in workload management, and ease-of-consumption issues which hardware advances alone cannot.
gb>> you are seeing the evolution now, The “cloud” is multi-dimensional some view as having six-layers... I like to just think of three, Infrastructure, Platform, Service...
gaberger
Dec 17, 2008, 2:48:28 PM12/17/08
to cloud-c...@googlegroups.com
See below:
Extended page tables (EPT). When this feature is active, the ordinary IA-32 page tables (referenced by control register CR3) translate from linear addresses to guest-physical addresses. A separate set of page tables (the EPT tables) translate form guest-physical addresses to the host-physical addresses that are used to access memory. As a result, guest software can be allowed to modify its own IA-32 page tables and directly handle page faults. This allows a VMM to avoid the VM exits associated with page-table virtualization, which are a major source of virtualization overhead without EPT.
Granted it is an abstract function which allows the VM to execute a traditional kernel based process (Ring 0) without exiting which would cause a context switch.
-g
http://www.intel.com/technology/itj/2006/v10i3/1-hardware/8-virtualization-future.htm
Extended page tables (EPT). When this feature is active, the ordinary IA-32 page tables (referenced by control register CR3) translate from linear addresses to guest-physical addresses. A separate set of page tables (the EPT tables) translate form guest-physical addresses to the host-physical addresses that are used to access memory. As a result, guest software can be allowed to modify its own IA-32 page tables and directly handle page faults. This allows a VMM to avoid the VM exits associated with page-table virtualization, which are a major source of virtualization overhead without EPT.
Granted it is an abstract function which allows the VM to execute a traditional kernel based process (Ring 0) without exiting which would cause a context switch.
-g
http://www.intel.com/technology/itj/2006/v10i3/1-hardware/8-virtualization-future.htm
--
Nik Simpson
Dec 17, 2008, 4:58:17 PM12/17/08
to cloud-c...@googlegroups.com
Dan Kearns wrote:
> On Wed, Dec 17, 2008 at 10:37 AM, Niels Goldstein
> <niels.g...@oracle.com <mailto:niels.g...@oracle.com>> wrote:
>
> Virtualization is a means to disconnect the running application from
> the underlying hardware. Its an enabling technology used by all the
> cloud computing
>
> ...etc
>
> We select servers based upon cost of CPU to Ram to Power and Space
> ratio. And that changes over time. Virtualization also gives us the
> freedom to select hardware at todays prices, and not feel locked
> into one vendor.
>
>
> So I buy some of these arguments, but by no means all. If you believe
> folks like James Hamilton, datacenter buildout at scale means you can
> reevaluate almost all your hardware assumptions without adding
> significant cost to the buildout, and with the potential of oom-sized
> operational benefits. It's hard for me to believe that current
> enterprise-focused hardware (eg blade servers, big sun or ibm boxes,
> etc) are what you'd choose.
>
> On Wed, Dec 17, 2008 at 10:37 AM, Niels Goldstein
> <niels.g...@oracle.com <mailto:niels.g...@oracle.com>> wrote:
>
> Virtualization is a means to disconnect the running application from
> the underlying hardware. Its an enabling technology used by all the
> cloud computing
>
> ...etc
>
> We select servers based upon cost of CPU to Ram to Power and Space
> ratio. And that changes over time. Virtualization also gives us the
> freedom to select hardware at todays prices, and not feel locked
> into one vendor.
>
>
> So I buy some of these arguments, but by no means all. If you believe
> folks like James Hamilton, datacenter buildout at scale means you can
> reevaluate almost all your hardware assumptions without adding
> significant cost to the buildout, and with the potential of oom-sized
> operational benefits. It's hard for me to believe that current
> enterprise-focused hardware (eg blade servers, big sun or ibm boxes,
> etc) are what you'd choose.
>
I certainly think that hardware in cloud data centers will change, for
example:
1. If reliability is being handled outside the hardware, then things
like redundant PSUs may not make sense, they suck power and do little
for the overall availability of the cloud.
2. If storage is consolidated, then why have space for 6-8 drives in
each server
3. External I/O virtualization in the form of MR-IOV expansion boxes
means you don't need to put room for lots of PCI slots in the
application servers
> Virtualization (assumed to mean os virtualization) clearly can ease
> operational cost for a legacy application stack, but it is a pretty
> blunt instrument to apply to things like workload management - you're
> essentially maximizing the size of your movable state, introducing an
> incredibly coarse-grained locking infrastructure, and adding
> considerable management complexity (eg blowing out your spanning trees
> just to preserve the mac you had, because the os doesn't expect that to
> change in a single tick) in exchange for preserving your current
> architecture. That's more than just a 5% runtime penalty.
Yeah, but its dirt cheap to do and well understood and sometimes that's
enough ;-)
>
> Krishna, as I'm totally ignorant on multi-core designs - is the primary
> power-saving benefit purely a packaging issue, eg sharing a power line
> amongst the cores vs adding a whole additional "card", or is it a more
> integrated thing where there are dynamic runtime benefits derived from
> shared componentry? ie if I have an 8-core cpu in a huge datacenter
> buildout, is it equivalent to expose that thing as if it were 8 separate
> "computers" vs one 8-cpu "computer"?
>
>
Multi-core is about two things:
1. GHz walls means that we can't simply make the CPU faster every year
by bumping the clock rate. Using multiple cores in a single CPU lets you
get some benefit from naturally parallel/multi-threaded bits of code
2. Putting multiple cores in a single CPU means that you can pack an
awful lot of processing cores in a single box which is attractive for
virtualization.
That's one of the additional benefits of virtualization. Without
virtualization I've got one OS hogging all the processors and probably
not making very effective use of them regardless of whether they are
eight discrete chips or a single chip with 8 cores.
--
Nik Simpson
Alka Gupta
Dec 17, 2008, 5:22:58 PM12/17/08
to cloud-c...@googlegroups.com
Utpal Datta wrote:
> >> BTW, IMHO, elasticity was never the goal of virtualization not can
> we achieve elasticity by virtualization – they are orthogonal
>
> As far as we know, Amazon is based on a Xen infrastructure (i.e.
> virtualization). How are they achieving elasticity and scalability?
Application needs to include additional software to enable
> >> BTW, IMHO, elasticity was never the goal of virtualization not can
> we achieve elasticity by virtualization – they are orthogonal
>
> As far as we know, Amazon is based on a Xen infrastructure (i.e.
> virtualization). How are they achieving elasticity and scalability?
scalability/elasticity. Tools like RighScale enable that. Amazon does
not have any magic wand to do that.
Alka.
>
> --utpal
>
>
> On 12/17/08, *Krishna Sankar (ksankar)* <ksa...@cisco.com
> <mailto:ksa...@cisco.com>> wrote:
>
> Dan,
>
> Good line of thought. Couple of points:
>
>
>
> a) Power efficiency – I think an 8 core machine (with 7.5 VM
> processes) would use less power than 8 small machines (say powered
> by via itx). But if one is using only one VM and one process, then
> the rest of the power is wasted
>
> b) Yes, from an enterprise IT application infrastructure
> perspective, virtualization s a short term solution with a cloud
> infrastructure as the long term goal
>
> c) Virtualization in some sense is getting more granularity
> than a hardware box (for better utilization) and that would
> eventually shift to the infrastructure providers
>
> d) BTW, IMHO, elasticity was never the goal of virtualization
> not can we achieve elasticity by virtualization – they are orthogonal
>
> e) Same goes with scale and ad-hocness
>
> f) And as you point out, virtualization has serious
> drawbacks – like multi-core and extra overhead.
>
>
>
> Cheers & happy holidays
>
> <k/>
>
>
>
> *From:* cloud-c...@googlegroups.com
>
> Dan,
>
> Good line of thought. Couple of points:
>
>
>
> a) Power efficiency – I think an 8 core machine (with 7.5 VM
> processes) would use less power than 8 small machines (say powered
> by via itx). But if one is using only one VM and one process, then
> the rest of the power is wasted
>
> b) Yes, from an enterprise IT application infrastructure
> perspective, virtualization s a short term solution with a cloud
> infrastructure as the long term goal
>
> c) Virtualization in some sense is getting more granularity
> than a hardware box (for better utilization) and that would
> eventually shift to the infrastructure providers
>
> d) BTW, IMHO, elasticity was never the goal of virtualization
> not can we achieve elasticity by virtualization – they are orthogonal
>
> e) Same goes with scale and ad-hocness
>
> f) And as you point out, virtualization has serious
> drawbacks – like multi-core and extra overhead.
>
>
>
> Cheers & happy holidays
>
> <k/>
>
>
>
> <mailto:cloud-c...@googlegroups.com>
> [mailto:cloud-c...@googlegroups.com
> <mailto:cloud-c...@googlegroups.com>] *On Behalf Of *Dan Kearns
> *Sent:* Wednesday, December 17, 2008 9:06 AM
> *To:* cloud-c...@googlegroups.com
> <mailto:cloud-c...@googlegroups.com>
> *Subject:* [ Cloud Computing ] why virtualization?
Tarry Singh
Dec 17, 2008, 5:57:42 PM12/17/08
to cloud-c...@googlegroups.com
Exactly. It is not the Guest but the supervisor module that acts as a special instantiation of that very guest, using the method called ring de-privileging.
/Tarry
/Tarry
Utpal Datta
Dec 17, 2008, 6:30:56 PM12/17/08
to cloud-c...@googlegroups.com
That software is needed whether it is virtualization or it is IaaS (e.g. Amazon) Right Scale is a lyer above Amazon, i.e. iwo layers from virtualization.
Still does not make virtualization and cloud (I mean IaaS) orthogonal as claimed by Shankar.
Would be curious to hear his answer.
--utpal
Jan Klincewicz
Dec 17, 2008, 6:49:15 PM12/17/08
to cloud-c...@googlegroups.com
As you state, multi-core is the only answer to the clock-rate challenge. While their are engineering constraints in terms of sharing cache, etc. they are more penalizing in traditional SMP architectures where little REALLY multi-threaded apps and OSs can take advantage of them, and more cycles are wasted as caches need to be "snooped" and memory arbitrated. While two dual-socket quad cores may not have the same raw compute power of a well-designed 8-socket box, it is by far more economical and simple to engineer and update for "commodity" motherboard designers.
In a virtualized environments, with sound CPU scheduling, multi-core systems truly allow multiple workloads to consolidate gracefully on single servers. Additionally, in the 32-bit world (where many apps are stilled mired for one reason or another, particularly in the Windows world) 4GB memory limitations constrain workloads while 80% and more CPU cycles rest idle.
By carving up small virtual machines out of these commodity-priced boxes, pretty amazing economies can be realized.
Blade architectures are an order of magnitude more efficient than traditional 1-U boxes, particularly when it comes to sharing power supplies and cooling fans redundantly. Unfortunately, they tend to be highly proprietary, but certainly less so than any viable alternative to off-the-shelf Taiwanese parts.
I would argue that Workload Management is relatively trival in a virtualized environment as well. With images reduced to files, current technology allows a single nine GB image to be streamed to dozens or hundreds of diskless servers over a 100MB network segment with no penalty on load or performance time. Abstracting an OS from a physical server's eccentricities allows an enormous amount of flexibility in delploying, and redeploying lad-balanced workloads (dynamically if desired) across arrays fo cheap servers.--
Cheers,
Jan
In a virtualized environments, with sound CPU scheduling, multi-core systems truly allow multiple workloads to consolidate gracefully on single servers. Additionally, in the 32-bit world (where many apps are stilled mired for one reason or another, particularly in the Windows world) 4GB memory limitations constrain workloads while 80% and more CPU cycles rest idle.
By carving up small virtual machines out of these commodity-priced boxes, pretty amazing economies can be realized.
Blade architectures are an order of magnitude more efficient than traditional 1-U boxes, particularly when it comes to sharing power supplies and cooling fans redundantly. Unfortunately, they tend to be highly proprietary, but certainly less so than any viable alternative to off-the-shelf Taiwanese parts.
I would argue that Workload Management is relatively trival in a virtualized environment as well. With images reduced to files, current technology allows a single nine GB image to be streamed to dozens or hundreds of diskless servers over a 100MB network segment with no penalty on load or performance time. Abstracting an OS from a physical server's eccentricities allows an enormous amount of flexibility in delploying, and redeploying lad-balanced workloads (dynamically if desired) across arrays fo cheap servers.
Cheers,
Jan
Jayadeep
Dec 17, 2008, 8:05:48 PM12/17/08
to Cloud Computing
I guess you can achieve elasticity without virtualization, but
virtualization enables or enhances elasticity by virtue of the
flexibility it brings. But I am not so sure if they are orthogonal,
but they sure are not directly related.
Jayadeep
On Dec 18, 1:00 am, "Utpal Datta" <utpal8...@gmail.com> wrote:
> >> BTW, IMHO, elasticity was never the goal of virtualization not can we
>
> achieve elasticity by virtualization – they are orthogonal
>
> As far as we know, Amazon is based on a Xen infrastructure (i.e.
> virtualization). How are they achieving elasticity and scalability?
>
> --utpal
>
> > cloud-c...@googlegroups.com] *On Behalf Of *Dan Kearns
> > *Sent:* Wednesday, December 17, 2008 9:06 AM
> > *To:* cloud-c...@googlegroups.com
> > *Subject:* [ Cloud Computing ] why virtualization?
virtualization enables or enhances elasticity by virtue of the
flexibility it brings. But I am not so sure if they are orthogonal,
but they sure are not directly related.
Jayadeep
On Dec 18, 1:00 am, "Utpal Datta" <utpal8...@gmail.com> wrote:
> >> BTW, IMHO, elasticity was never the goal of virtualization not can we
>
> achieve elasticity by virtualization – they are orthogonal
>
> As far as we know, Amazon is based on a Xen infrastructure (i.e.
> virtualization). How are they achieving elasticity and scalability?
>
> --utpal
>
> On 12/17/08, Krishna Sankar (ksankar) <ksan...@cisco.com> wrote:
>
>
>
> > Dan,
>
> > Good line of thought. Couple of points:
>
> > a) Power efficiency – I think an 8 core machine (with 7.5 VM
> > processes) would use less power than 8 small machines (say powered by via
> > itx). But if one is using only one VM and one process, then the rest of the
> > power is wasted
>
> > b) Yes, from an enterprise IT application infrastructure perspective,
> > virtualization s a short term solution with a cloud infrastructure as the
> > long term goal
>
> > c) Virtualization in some sense is getting more granularity than a
> > hardware box (for better utilization) and that would eventually shift to the
> > infrastructure providers
>
> > d) BTW, IMHO, elasticity was never the goal of virtualization not can
> > we achieve elasticity by virtualization – they are orthogonal
>
> > e) Same goes with scale and ad-hocness
>
> > f) And as you point out, virtualization has serious drawbacks – like
> > multi-core and extra overhead.
>
> > Cheers & happy holidays
>
> > <k/>
>
> > *From:* cloud-c...@googlegroups.com [mailto:
>
>
>
> > Dan,
>
> > Good line of thought. Couple of points:
>
> > a) Power efficiency – I think an 8 core machine (with 7.5 VM
> > processes) would use less power than 8 small machines (say powered by via
> > itx). But if one is using only one VM and one process, then the rest of the
> > power is wasted
>
> > b) Yes, from an enterprise IT application infrastructure perspective,
> > virtualization s a short term solution with a cloud infrastructure as the
> > long term goal
>
> > c) Virtualization in some sense is getting more granularity than a
> > hardware box (for better utilization) and that would eventually shift to the
> > infrastructure providers
>
> > d) BTW, IMHO, elasticity was never the goal of virtualization not can
> > we achieve elasticity by virtualization – they are orthogonal
>
> > e) Same goes with scale and ad-hocness
>
> > f) And as you point out, virtualization has serious drawbacks – like
> > multi-core and extra overhead.
>
> > Cheers & happy holidays
>
> > <k/>
>
> > cloud-c...@googlegroups.com] *On Behalf Of *Dan Kearns
> > *Sent:* Wednesday, December 17, 2008 9:06 AM
> > *To:* cloud-c...@googlegroups.com
> > *Subject:* [ Cloud Computing ] why virtualization?
Utpal Datta
Dec 17, 2008, 9:45:54 PM12/17/08
to cloud-c...@googlegroups.com
No one said that elasticity is achievable only thru virtualization. Technologies like Grid, Beowulf was happily being elastic when VMWare was in kindergarten.
Shankar claimed that elsticity cannot be achieved by virtualization. I was curious about the validity and reasons behind that statement.
The bigger implication is that available compute resources of enterprise ITs which are moving at a breakneck speed towards virualization, cannot be made to behave (just as elastic as EC2) like the external cloud.
It is much easier for the enterprise to adopt a internal cloud (no security, data movement issues) and effectively deal with "cloud-burst" as well as much higher utilization, just using virtualization and some smart software which orchestrate the whole thing.
Ofcourse the applications which can take advantage of this will have to be smartly re/written by smart people :-)
Anyone sees any problem with what is stated above?
S.R. Venkatramanan
Dec 17, 2008, 11:12:41 PM12/17/08
to cloud-c...@googlegroups.com
Dan Kearns wrote:
>
> If the goals are to have smarter software and maximize utilization (or
> minimize power consumption for equivalent compute capacity), then why
> introduce the constant runtime overhead of virtualization instead of,
> eg using smaller more power-efficient compute-unit designs and making
> the hardware controllable by software?
What you say here 'smaller units controllable by software' is what is
the purpose of OS kernel, as you know, but commodity boxes do not
provide that many such 'smaller units'. That is the problem Azul
(http://www.azulsystems.com) solves by packing in excess of 760 compute
units (and equal number of GB) in one box and have its specialized
software (OS) control allocation of those units on demand and by policy.
The only limitation there is that, it only knows how to execute Java.
You can have one JVM take all the cores in the box (when you have a
highly parallelized application) or several VMs dynamically share those
cores and memory subject to policy constraints. So, in your
terminology, an Azul domain with one or more Azul boxes becomes a
'girddized' cloud with a special purpose. Obviously, this won't serve
well for single threaded applications.
btw, this arrangement also gives the opportunity to have a huge heap for
one VM with practically no GC pause!
rgds,
S.R.
Krishna Sankar (ksankar)
Dec 18, 2008, 1:44:07 AM12/18/08
to cloud-c...@googlegroups.com
Now I have to chime in ;o) (Dan, see what you got me into !)
I did not say elasticity cannot be achieved by virtualization (notice the double negative ;o)); I also didn’t say for elasticity, virtualization is needed ! My point was, they are orthogonal – elasticity can be achieved with or without virtualization. In other words, virtualization is neither a necessity nor a prerequisite for elasticity.
Cisco has a product called VFrame which does provisioning and in old days (may be even now) it turns on and off real hardware to get additional capacity. (This is just an example – I am neither advocating for nor against VFrame, in this context) You can have a perfectly good cloud in that way.
Having said that, the hypervisors give us couple of things; first - the ability to move VMs around; I am not sure if it also gives us VM expandability as that requires a bit more than just a VM change (applications need to reallocate buffers, move boundaries et al); second - it offers us more granularity and efficient use of hardware. I am not aware of any technology to pickle a running machine and resurrect it somewhere else as easily as the VM motion technologies.
Going back to Dan’s original question, for an application - say a hadoop cluster, would virtualization give any advantage ? Same goes with Utpal’s examples of grids and clusters.
Let me stop before I get into more trouble ;o)
Cheers
<k/>
BTW, the logic which says because Amazon is based on XEN, virtualization is required for elasticity is not logical. Amazon also sells books and that doesn’t mean for elasticity one should sell books ;o) But the second order effects of having an infrastructure which sells lots of books do help (engineers who understand scalability, idle resources when books are not in high demand, a retail mindset and so forth)
From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Utpal Datta
Sent: Wednesday, December 17, 2008 6:46 PM
To: cloud-c...@googlegroups.com
Mauro TINELLI
Dec 18, 2008, 4:11:30 AM12/18/08
to cloud-c...@googlegroups.com
Jan, you say:
"In a virtualized environments, with sound CPU scheduling, multi-core systems truly allow multiple workloads to consolidate gracefully on single servers."
Not quite since unfortunately today (still):
"Blade architectures are an order of magnitude more efficient than traditional 1-U boxes, particularly when it comes to sharing power supplies and cooling fans redundantly. Unfortunately, they tend to be highly proprietary, but certainly less so than any viable alternative to off-the-shelf Taiwanese parts."
and also when it come to cost per unit and memory scalability the 1U servers are still the winners. In fact as you grow with the number you grow with the CAPEX and that's still the 1st hurdle to overcome.
Ciao, Mauro
"In a virtualized environments, with sound CPU scheduling, multi-core systems truly allow multiple workloads to consolidate gracefully on single servers."
- as cores/cpu ratio increase performances go down, due to contention on the bus & clock, etc. Dual-cores may perform globally better than 4+ cores.
- software licensing is a mess, e.g.
- Oracle is per core and highest clock are convenient (IBM pSeries may be cheaper than x86!!)
- VMware is per Processor, the more cores the cheaper.
"Blade architectures are an order of magnitude more efficient than traditional 1-U boxes, particularly when it comes to sharing power supplies and cooling fans redundantly. Unfortunately, they tend to be highly proprietary, but certainly less so than any viable alternative to off-the-shelf Taiwanese parts."
Ciao, Mauro
Jan Klincewicz
Dec 18, 2008, 9:12:11 AM12/18/08
to cloud-c...@googlegroups.com
I'm not sure of the validity of all your statements. VMware's multi-core licensing statement does not mention anything above 2-socket machines (at this time accommodating 6-core processors.) See what happens when you try to license a 4-socket machine (and those are typically the boxes with the most DIMM slots !!)
http://www.vmware.com/download/eula/multicore.html
I don't know ... This statements is as of September 15th (first day of VMWorld.) I would be interested in finding out the answer.
Oracle has ALWAYS had byzantine pricing schemes, so yes, for Oracle environments. You may be better off with a mainframe running Oracle (and I suspect they will need to change their ways eventually.)
Dual cores MAY perform better than quad or hex in SOME CIRCUMSTANCES, but you need to examine architectures such as AMD Opteron where there IS no front-side bus contention,and memory is more NUMA-like. Intel also, is soon to adopt on-die memory controllers if they have not already.
I would also argue that TCO vs. CAPEX is a valid argument, regardless of how tired people are of hearing it. Acquisition costs are MINIMAL compared to ongoing maintenance, and especially administration. Servers are cheap, ESPECIALLY when virtualized. I find it difficult to argue against virtualization in this day and age. Of course, I am biased, being a XenServer SE, but customers sure seem to be getting it, and I don't see how cloud providers would be less affected by the economies inherent in this technology.--
Cheers,
Jan
http://www.vmware.com/download/eula/multicore.html
I don't know ... This statements is as of September 15th (first day of VMWorld.) I would be interested in finding out the answer.
Oracle has ALWAYS had byzantine pricing schemes, so yes, for Oracle environments. You may be better off with a mainframe running Oracle (and I suspect they will need to change their ways eventually.)
Dual cores MAY perform better than quad or hex in SOME CIRCUMSTANCES, but you need to examine architectures such as AMD Opteron where there IS no front-side bus contention,and memory is more NUMA-like. Intel also, is soon to adopt on-die memory controllers if they have not already.
I would also argue that TCO vs. CAPEX is a valid argument, regardless of how tired people are of hearing it. Acquisition costs are MINIMAL compared to ongoing maintenance, and especially administration. Servers are cheap, ESPECIALLY when virtualized. I find it difficult to argue against virtualization in this day and age. Of course, I am biased, being a XenServer SE, but customers sure seem to be getting it, and I don't see how cloud providers would be less affected by the economies inherent in this technology.
Cheers,
Jan
Dan Kearns
Dec 18, 2008, 10:59:46 AM12/18/08
to cloud-c...@googlegroups.com
On Wed, Dec 17, 2008 at 8:12 PM, S.R. Venkatramanan <s...@computer.org> wrote:
commodity boxes do not
provide that many such 'smaller units'. That is the problem Azul
(http://www.azulsystems.com) solves by packing in excess of 760 compute
units (and equal number of GB) in one box and have its specialized
software (OS) control allocation of those units on demand and by policy.
Good point. The Azul stuff is pretty cool, and if I understand you, it sounds like it is now more or less multi-tenantizable?
Given that there are providers out there basing cloud-ish offerings (by which I mean mostly automated provisioning, no long-term contracts, and capacity-based pricing) on tech from Xen, 3tera, VirtualIron, Sun, and Msft (did I miss any?), I'm wondering why there is no provider offering an Azul-based service? For that matter, why is there no provider offering z/os based service? Wouldn't that be a pretty cheap way to get thousands of lamp stacks online?
-d
Jason Ding
Dec 18, 2008, 12:53:02 PM12/18/08
to cloud-c...@googlegroups.com
My understanding is Azul's solution is JVM-only.
The "generic" VM solution allows different flavors of guest VMs that can host legacy apps.
The "generic" VM solution allows different flavors of guest VMs that can host legacy apps.
/jd
From: Dan Kearns <dan.k...@gmail.com>
To: cloud-c...@googlegroups.com
Sent: Thursday, December 18, 2008 7:59:46 AM
Subject: [ Cloud Computing ] Re: why virtualization?
Jose Gonzalez
Dec 18, 2008, 3:19:01 PM12/18/08
to cloud-c...@googlegroups.com
The assumption is correct. However, with all of the proliferation of dynamic languages running on the JVM, you could still use Azul's solution for, let's say, Ruby on Rail if you are willing to run it from a JVM compatible interpreter like Jruby. Technically, the same applies to other languages. For more info on this, check the presentation made by Cliff Click from Azul Systems
http://www.infoq.com/presentations/click-fast-bytecodes-funny-languages
According to Cliff, he was able to run a DOS version of Prince of Persia running on JPC. It was because of his comments that I started looking into JPC seriously as a way to run pretty much any old code that you may have running on a plain old vanilla PC. There might not be much use for that, but the need might be there for some users.
Jose Gonzalez
{Open} Virtual Computing
http://www.infoq.com/presentations/click-fast-bytecodes-funny-languages
According to Cliff, he was able to run a DOS version of Prince of Persia running on JPC. It was because of his comments that I started looking into JPC seriously as a way to run pretty much any old code that you may have running on a plain old vanilla PC. There might not be much use for that, but the need might be there for some users.
Jose Gonzalez
{Open} Virtual Computing
From: Jason Ding <jaso...@yahoo.com>
To: cloud-c...@googlegroups.com
Sent: Thursday, December 18, 2008 12:53:02 PM
Subject: [ Cloud Computing ] Re: why virtualization?
Kenneth Westerby
Dec 18, 2008, 4:19:14 PM12/18/08
to cloud-c...@googlegroups.com
I can see why this seems contradictory, but if you think about from a
different point of view it may be easier to split them apart.
The Cloud has benefits for the end users, applications or service by
offering capacity, storage, performance or what you need on demand.
The Virtualization has benefits for the cloud by facilitating the
managment the HW/SW and processes that is needed for creating the
foundations of the cloud.
Kenneth
different point of view it may be easier to split them apart.
The Cloud has benefits for the end users, applications or service by
offering capacity, storage, performance or what you need on demand.
The Virtualization has benefits for the cloud by facilitating the
managment the HW/SW and processes that is needed for creating the
foundations of the cloud.
Kenneth
Jan Klincewicz
Dec 18, 2008, 8:40:28 PM12/18/08
to cloud-c...@googlegroups.com
That is quite correct.
As I have been fond of pointing out since I have been on this forum, there are two distinct groups interested in CC; Users and Providers. Users don't (and should not) give a crap about architecture, CPU design, Storage, Protocols, etc. They should be concerned with SLAs, and software that meets their business needs, 24X7.
PROVIDERS on the other hand are the same sorry S.O.B.s that are now saddles with running Data Centers for USERS, and are still faced with all the SAME decades-old issues of which the USERS are trying to rid themselves... and make a few bucks in the process.
Virtualization is far cheaper than dedicating hardware, and utilizes same much more cost effectively. If it did not reduce hardware and management costs nobody would care about it.--
Cheers,
Jan
As I have been fond of pointing out since I have been on this forum, there are two distinct groups interested in CC; Users and Providers. Users don't (and should not) give a crap about architecture, CPU design, Storage, Protocols, etc. They should be concerned with SLAs, and software that meets their business needs, 24X7.
PROVIDERS on the other hand are the same sorry S.O.B.s that are now saddles with running Data Centers for USERS, and are still faced with all the SAME decades-old issues of which the USERS are trying to rid themselves... and make a few bucks in the process.
Virtualization is far cheaper than dedicating hardware, and utilizes same much more cost effectively. If it did not reduce hardware and management costs nobody would care about it.
Cheers,
Jan
Barry Allard
Dec 18, 2008, 8:49:41 PM12/18/08
to cloud-c...@googlegroups.com
Hi Dan,
Perhaps the following is of some use.
Cloud, grid, utility computing, virtualization and mainframe are buzzwords that come and go with the wind. It's how services are sensibly constructed for usable interoperability with solid managing processes and support that persists indelibly.
From gate-level ASIC EDA to search algorithms to UI design to captology, there's a host of specialized complexity most people don't want to delve into, nor should they for most applications. Most solutions are very easy and repeatable.
To maximize business value of assets, it is necessary to reconsider what absolutely matters and where duplication exists and can be removed practically. Hence, the idea of a soon-to-be-accepted notion of secure, self-optimizing cloud server and storage appliances for the enterprise reducing silos and providing a comprehensive platform of shared/hosted infrastructure service solutions.
The case for virtualization is simple:
1) Make better use of existing resources without altering system software, e.g., idle servers are wasted assets.
2) "Food Groups" Scalability, Isolation and Policy, i.e., mainframe-like resource limits in Vmware ESX
- Processing
- Memory
- Network I/O
- Disk I/O
3) Ease of deployment, reconfiguration.
The possible consequences are:
4) Concentrated risk - most software and applications are not truly distributed and fault-tolerant, less experienced IT staff are able to break more systems faster.
5) Theoretical security risks of shared memory reading from other VMs or phantom VM guests.
6) Debatable overhead of virtualization, paravirtualization.
7) Increased complexity: more resources to monitor and manage.
8) Overuse due to ease of additional deployments, reconfiguration.
9) Inappropriate application of virtualization, i.e., high load systems: hi-cap database, email and hpcc.
The risks may seem numerous, but the benefits generally outweigh risks unless the IT staff are completely clueless, the task is highly-specialized or the scale is massive. You should see the racks of systems carted away from virtualization migrations!
Delving deeper into CS and futurism: there's no theoretical need for more than one conceptual system if it is perfectly capable of secure partitioning (read: mainframe). Practically, software is no where near as good as it could be because it grew organically and because people put up with it. Try shared hosting of multiple https domains with apache on one ip address. Good luck!
The key is making hybrid clusters of many individual computing assets function like one single appliance. Rocks clusters, vmware esxi, vdi are moving in the right direction.
No one wants to change the underlying software or make computing more difficult because that would be too much change, too soon. What is needed is smart languages and compilers that automatically parallelize and distribute ACID & RESTful loads appropriately to available capacity with minimum overhead and assuring compliance to the SLA. The algorithm is related to effective freight forwarding or newtonian packing of circles.
Reimplementing architectures for fault-tolerant, distributed "griddy" local clouds and shared/hosted SaaS is the most necessary goal. Windows, Apple, Linux; PHP, Ruby, Python apart from politics or features, they're all of equivalent Turing power. The suite of effective capability delivered to the user is what truly matters.
Many systems are refactorable in terms of just a few services within a robustly distribute architecture:
- web services
- application / business logic
- database
- file storage
Barry Allard, VCP
gaberger
Dec 19, 2008, 12:39:01 PM12/19/08
to cloud-c...@googlegroups.com
Awesome, this is exactly the foresight we need to transform. The message on the front-side is give the user the capability to access information and collaborate on any device (he/she) wants and make the underlying back-end transparent.
From the operations side we want the infrastructure to look and behave like a single “limit-less” computer with data coherency, partitioning, and messaging built in. Not that this is easy, hence a lot of work under the data control plane to make the communication path fair and determinant. This is a factor of scale not of capability.
-g
From the operations side we want the infrastructure to look and behave like a single “limit-less” computer with data coherency, partitioning, and messaging built in. Not that this is easy, hence a lot of work under the data control plane to make the communication path fair and determinant. This is a factor of scale not of capability.
-g
--
Reply all
Reply to author
Forward
0 new messages