VMware hyper-converge means we don't need no STEENKIN' OS... With VMware converging storage - VSAN - and networking - Nicira - into the hypervisor, it’s re-inventing the server operating system. Chuck Hollis, chief strategist at VMware’s SAS business unit, has blogged about this convergence. He reckons that we’re seeing hardware convergence, mentioning flash coming into the server via …
I'm pretty sure they just invented *nix with X protocol. Many users can fire up different apps remotely on an OS and render the output locally on an X compatible terminal. This technology has been around for over 30 years. Why exactly is a full fat hypervisor even remotely relevant here? If we are looking to cut out layers, let's throw away the hypervisor as well, and just have a decent full-featured OS on the back of it all like we have been doing for decades?
Why this unhealthy obsession with virtualization purely for buzzword compliance?
"Why this unhealthy obsession with virtualization purely for buzzword compliance?"
Virtualisation isn't really needed for grown up OS's (read unix variants), but its a must for Windows which has never been able to compartmentalise anything particularly well. Hence you have dedicated servers for mail, DB etc.
And yes, its partially about buzzwords, marketing hype (pun intended) and a wardrobe of emporor news clothes.
"Windows which has never been able to compartmentalise anything particularly well."
Actually Windows does that better than *NIX - because it has a hybrid microkernel it can provide true driver level isolation, not roll them all into 1 kernel like in the *NIX world....
"Hence you have dedicated servers for mail, DB etc."
I tend to see far more multi-application deployments on Windows than Linux / UNIX ones....Microsoft Small Business Server is the most obvious example that blows your theory out of the water...
"I tend to see far more multi-application deployments on Windows"
I'm not sure what world you live in, but our environment is highly isolated because Corporate Application 1 requires Software Stack 1 which is DIRECTLY incompatible with Software Stack 2 which is required by Corporate Application 2 and 3.
Not only that, but who wants to be rebooting their mail server, domain controller, web server, etc all-in-one SBS server just because an Exchange patch was pushed out? Windows still requires reboots for several items. *NIX environments can be patched/updated on-the-fly (got to love the ability to overwrite a file currently in use) and the components simply reloaded.
"Actually Windows does that better than *NIX - because it has a hybrid microkernel it can provide true driver level isolation, not roll them all into 1 kernel like in the *NIX world...."
Wtf are you talking about? Applications generally don't give a rats backside about hardware drivers. They DO care about dlls and config being stomped on by other apps. When Windows comes with containers or even the equivalent of chroot (been around for 30 years in unix) built in get back to me.
"I tend to see far more multi-application deployments on Windows than Linux / UNIX ones....Microsoft Small Business Server is the most obvious example that blows your theory out of the water..."
Riiiight. Currently just one of our work Linux boxes has 3 separate Oracle database servers, 60 odd simultanious shell users and about 80 seperate application programs running not including standard system processes such as sendmail, ftp and an apache web server. And thats just an off the shelf Dell blade. Try that with windows server and watch it die painfully.
SQL must be run in virtual environments! There is no other way for any business relying on SQL to manage its estate of databases! You cannot run SQL on a bare tin system! You must run your data store local in the VM! You must...
Sometimes I wish I had never gotten into IT.
Given the enormous inefficiencies involved in virtualising an RDBMS, you have to assume that this is a cunning plot by Intel to sell lots more 15-way Xeons.
I suspect that at some point the increasing virtualisation overhead will overtake Moore's Law, and database performance will start going backwards even as the vendors propose even more virtualisation to overcome the problems. See Alice in Wonderland for details.
> Not exactly enormous inefficiencies
May I ask why you chose to virtualise at all? And when you included the cost of vmware and the cost of admining it (extra staff? infrastructure? training?) how much did that offset the savings in the sql server licensing (and how much was that saving anyway?)
thanks
"May I ask why you chose to virtualise at all"
Because some SQL type applications want dedicated OS images. Or for test / dev purposes need to be isolated. We also have a large clusters on dedicated tin for more conventional deployments.
"And when you included the cost of vmware"
I didn't. Hyper-V Server is free...
"and the cost of admining it (extra staff? infrastructure? training?) "
I would say it was cheaper then the costs of deploying new physical servers. No extra staff needed - If anything less time spent building the new server. Staff are already skilled.
"you don't think 9% is a lot?"
That's worse case. And no I don't - that's insignificant versus the benefits. I get more varience than that from how busy our storage is...
Ok, thanks.
Assuming you are running mssql (seems likely if you're on windows) then "Or for test / dev purposes need to be isolated", well, that's what the developer edition is for, cost ~£50. I haven't looked at the swamp of mssql licensing recently but the big money is charged for live deployments. They don't care how you use it for dev/training. so if I'm right (please check) virt isn't needed here.
Actually I'm a little dubious about this "Because some SQL type applications want dedicated OS images". Servers are meant to be just that so an app should not care (or indeed be able to tell) whether it's running on the same machine as the sql install, or remotely. I'm not understanding something here. Possible they require server-level config settings which would conflict with the other installs I suppose...
This post has been deleted by its author
"Assuming you are running mssql"
The same is true of Oracle too. Except that Oracle don't seem to acknowledge virtualisation for licensing, so a dedicated VM Host is required. And hence also why Oracle is disinvest here...
"well, that's what the developer edition is for, cost ~£50"
That doesn't help with production systems. Or solve the isolation requirements.
"so if I'm right (please check) virt isn't needed here."
The isolation is nothing to do with licensing. It's so that you don't impact production systems if they were running on the same box...
"I would say it was cheaper then the costs of deploying new physical servers. No extra staff needed - If anything less time spent building the new server. Staff are already skilled."
If you used a half decent OS you could have multiple instances of various databases running on the same physical box, no hypervisor required. I assume you must use Windows however.
> If virtualisation is the way forward, why does Microsoft put so much effort into being able to run multiple MSSQL instances per server?
don't be a fucking numpty. Named instances go back further than MS's virtualisation work, and a named instance isn't going to be "so much effort". It's basically the same software with slightly different configs.
Also virtualisation has many other uses than virting a DB server (as far as I can tell, most other uses *are* better uses than virting a DB)
"If you used a half decent OS you could have multiple instances of various databases running on the same physical box, no hypervisor required. I assume you must use Windows however."
And if you had half decent comprehension, you would have noticed that it says "We also have a large clusters on dedicated tin for more conventional deployments".
"Our testing showed only about a 9% maximum performance drop versus native tin - often much less"
So when different vendors are promoting their wares based on single digit differences between them and their competitors in various metrics, you don't think 9% is a lot? Riiiight...
"Our testing showed only about a 9% maximum performance drop versus native tin"
On what RDBMS/OS/hypervisor? Throughput of carefully tuned MySQL on Linux under ESXi at full saturation (100% CPU usage with at least twice as many concurrent active threads as there are CPU cores, hot pre-primed caches, read-only) drops by about 40% when you run virtualized on the same hardware with full hardware virtualization support. KVM is a little worse, Xen is a little less bad, but the difference is in the low single-figure % points.
Did your comparison involve pushing the server to the limit with a highly concurrent load or were you just measuring latency under low load?
"On what RDBMS/OS/hypervisor?"
Both Oracle 11g and SQL 2012 / Windows Server 2012 / Hyper-V Server 2012.
"MySQL on Linux"
Sorry we don't have any niche requirements like that.
"at least twice as many concurrent active threads as there are CPU cores, hot pre-primed caches, read-only"
We ran a production like configuration. Close match to virtual and physical cores, and a mixed workload timed script run once to warm up before being run again to be measured.
"Did your comparison involve pushing the server to the limit with a highly concurrent load"
Yes, we maxed out CPU before storage, but storage was still under a high load.
See also:
https://blogs.vmware.com/apps/sql
"Virtual performance is (within) about 5-6% of physical for most business critical application workloads" - which matches what we found fairly closely.
I've been saying this for years. It gets even worse when you consider higher level VMs (e.g. Java, C#, etc)
- The language VM is designed to isolate the application from the operating system/processor.
- The operating system is designed to isolate the application from the hardware (and other applications).
- The hypervisor is designed to isolate the operating system from the hardware (and other operating systems).
There is so much duplication of isolation/abstraction going on here.
One of the reasons I think it's arisen is because applications kinda assume they're the only application running on an operating system. So a second application can come along and do something to the environment that upsets the first one. DLL/Shared library hell is just one example of this. I remember working on an Oracle system a few years ago. Oracle refused to support us if we installed Apache on the same system as the Oracle Database. But if we virtualised them both and ran them on the same physical server, Oracle were happy.
Another reason is that applications are often coded to expect a very explicit setup. I've seen PCs built with four or five versions of Java installed as each application was hard coded to only run on a particular patch/version of the JVM. I've also seen applications say "We only support Windows X, with Service Pack Y, and Hot Fixes A, B & C"
I can understand where VMWare are coming from. But at the minute their "O/S" is a very basic O/S. They'll add new features into their O/S to flesh it out, until, it balloons and we accuse them of bloating their system with unnecessary features and doing a Microsoft.
But you'll just end up with application vendors saying "We only support VMware Version x.y.1, not x.y.2" (This is already happening with some vendors...)
Then someone will invent a hypervisor for hypervisors...
Run several instances of Windows 7 pro on a hypervisor, then run XP in each one, and you now have your hypervisor for hypervisors.
Your comment seems to me to be spot on. In mainframes, careful planning is needed to make the most effective use of expensive resources. PC servers are still perceived as relatively cheap, hence shoddy application planning, poor JVM compatibility and all the other signs of corner cutting. The proposed solution, virtualisation, is never going to be as good as somehow getting application vendors to work to common standards.
I'm extremely glad to have recently retired and not have to work with Java any more, but I have to say that my experiences with .NET were much, much worse.
"Run several instances of Windows 7 pro on a hypervisor, then run XP in each one, and you now have your hypervisor for hypervisors."
To run Windows XP under Windows 7 - Windows 7 needs access to CPU hardware assisted virtualisation features. Not possible if you are already running under a hypervisor...
Of course VMware would much rather you used their storage management and got all nicely locked into their volume formats at so forth.
Because why would you want to use anything native to your storage array? What do you mean, "some of your stuff isn't in VMDKs" ? I hope you don't use bare metal servers. Please call our sales staff immediately.
Whatever you run in VMs must still provide system services like I/O, memory management and higher level APIs to applicaitons. You could run an app on a bare VM (which is how VM/CMS, the grand-daddy of them all worked) but you would have to link to libraries providing those services.
For some apps such as DBMS platforms you could arguably make a case for running them with a minimal set of kernel services directly linked into the server. Oracle have been banging on about DB appliances built like this since at least the 1990s.
However, there aren't many application s for which this would be particularly beneficial - at least where it would be cost effective to do this. Developing applications for that type of architecture is much harder and more expensive than developing against a platform that provides a comprehensive set of system services. In short, there is little to recommend this type of platform outside of a handful of specialised applications.
Providing system services through the hypervisor simply turns it into an operating system with a very heavy context switching overhead, likely to be quite inefficient. Far better to provide an O/S kernel with paravirtualised drivers against raw I/O and memory seriices provided by the hypervisor, which is largely how it's done now.
If you wanted a minimal kernel it is certainly possible to strip Linux or one of the BSDs down to a minimal set of system services, but this may or may not be particularly useful. One possible benefit is improve runtime security by removing unnecessary services that could provide attack vectors - in which case you've really just re-invented OpenBSD.
One point to note is that we used to get on just fine without hypervisor sprawl and that *nix or mainframe architectures could run enormous portfolios of applications without needing to split each one into it's own VM. Modern VMs are largely a solution to problems originating from the Windows DLL Hell era, and that has been a substantially solved problem for a decade or more..
That is not to say that VMs aren't useful, but in many cases they are a sledgehammer to crack a walnut. The current technology of paravirtualised services where the O/S kernel has drivers to support services provided reasonably efficiently by the hypervisor allows the O/S to be used with or without a VM. The O/S provides the system services and the VM allows multiple O/S images to be consolidated onto a shared hardware platform. You can run your O/S and applications against a VM or against bare metal. Job done.
"Far better to provide an O/S kernel with paravirtualised drivers against raw I/O and memory seriices provided by the hypervisor, which is largely how it's done now."
Erm no it isn't. Both market leaders - Hyper-V Server and VMware - use a dedicated Hypervisor layer (Hyper-V can also optionally run under Windows Server but this is not required).
Linux based Hypervisors have to bolt on an OS kernel, and the most popular such product (KVM) has ~ 1% market share, and the performance and scalability of production KVM versions lags someway behind VMWare and Hyper-V.
"Modern VMs are largely a solution to problems originating from the Windows DLL Hell era, and that has been a substantially solved problem for a decade or more."
Doesn't look solved to me, but perhaps I have a different take on the first half of your sentence. Modern VMs are the solution to Windows being too willing to let independent processes party on each other (and on the OS). Mainframes had VM and UNIX had chroot long before Windows had a hypervisor. These solve the isolation problem *within* the OS, but since Windows is closed and Microsoft are apparently unwilling to introduce similar facilities, the only way to solve the problem was to emulate entire machines and stick a separate copy of Windows in each one.
Since we still have Windows, I can't see that the problem is "substantially solved", unless you are being particularly cutting about the inability of Microsoft to produce a popular successor to XP and their consequently dismal long term prospects in the OS market.
Isn't this what an HPC system in a bank looks like? Large pool of servers presented as a single logical pool of compute that then has a policy applied to it as applications execute. However, no need for a hypervisor as they just get in the way of performance - around 5-15% depending on application type.
I think the opposite is probably true of what's presented in the story - infrastructure virtualisation is a short/medium term problem due to legacy applications having to be tightly coupled to an operating system of their own - they don't share nicely together. Move up to a PaaS built application and hardware virtualisation becomes somewhat irrelevant.
As mentioned by John Sanders, this is more or less the definition of a container.
Solaris zones, *BSD jails, more recently LXC and OpenVZ on Linux are all examples of isolation technologies that would meet your "We don’t really need no stinking Windows or any other OS in the virtual machines" point.
It looks like we have rediscovered the basic, humble time-sharing system.
The IT industry, true to form, just keeps on rediscovering the solutions to problems that were solved decades ago, and then rediscovering the problems when they try to apply the "new, improved" solutions to replace the elegant ones that have been working well for decades.
Virtualization was always a case of the Emperor's New Clothes.
OSv is a new open source operating system designed to run on top
of a hypervisor. It's designed exactly to answer the above reasons w/ performance,
efficiency and manageability in mind. Check www.osv.io (Apha version will be
released at the end of the quarter)
We never did...and we didn't need no steenkin' VMware either till Windows came along and started pretending to be a server OS.
Unfortunately the IT industry, particularly management's obsession with virtualisation came about with the ever increasing presence of Windows in the server space over the last decade. And it's been buzzword driven to ridiculous extremes and the unix world has had to play along with it. It's a solution to a problem that never was, on Unix. Like several others smarter than I have commented above, every imaginable "resource" can be isolated and controls set between disparate applications and it's processes under one instance of the OS. Virtualisation with multiple OS instances on unix is redundant in most cases and serve no purpose other than to sell more software and support licenses. I suppose having more OSs to manage also helps Unix/Linux admins appear busier to management with their limited windows only worldview.
Everything nowdays is aimed at getting as much penetration into an environment so that it is impossible to change supplier. This is the big game of the major vendors, whether it be locally implemented virtualisation, storage, networking or cloud services.
The reality is that VMware has to generate revenue somewhere and whilst people persist in this utopian view that the only way is virtualistion they are only going to win. I am not saying that virtualisation does not have a place, it does. It can provide significant cost savings, particularly on application servers but many of the reduced costs are now being eaten by evering increasing amounts of management software that is needed.
A large physical MSSQL cluster or Exchange implementation will always be better than a virtualised one. The compromises one has to make to virtualise are plain stupid. What is the point have having a DAG virtualised when Exchange is handling all the replication adn failover. It is simply adding a layer of cost and complexity that is not required. The resources needed for the Exchange implementation would end up with a 1:1 vm to host mapping anyway. The storage becomes a complete nightmare.
An HP SL4540 is the perfect box with a rack density that is very hard to improve on. With SQL to make the licensing work you have to dedicate a pool of servers and it ends up costing more than the physcal cluster. It is pointless to cluster on VMware as so much functionality is lost.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
