Become a fan of Slashdot on Facebook


Forgot your password?

Ask Slashdot: What Type of Asset Would You Not Virtualize? 464

An anonymous reader writes "With IT and Data Center consolidation seemingly happening everywhere our small shop is about to receive a corporate mandate to follow suit and preferably accomplish this via virtualization. I've had success with virtualizing low load web servers and other assets but the larger project does intimidate me a little. So I'm wondering: Are there server types, applications and/or assets that I should be hesitant virtualizing today? Are there drawbacks that get glossed over in the rush to consolidate all assets?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Type of Asset Would You Not Virtualize?

Comments Filter:
  • Re:Busy databases (Score:5, Interesting)

    by Maskirovka ( 255712 ) on Thursday May 31, 2012 @08:25PM (#40174845)

    Shared disk does not make I/O happy.

    PCIE SSDs are advertised to deliver 100,000 to 500,000 IOPs. Has anyone experimented with PCI-Express based SSD solutions in their VM hosts to keep high IO VMs like VDI and SQL from swamping their SAN infrastructure? []

  • Re:Sure (Score:3, Interesting)

    by The1stImmortal ( 1990110 ) on Thursday May 31, 2012 @08:37PM (#40174959)

    VMware ESXi is actually a supported guest for VMware Workstation...

    Whilst that may sound crazy, it makes system design, testing, and generally skilling up a lot easier.

  • by netsavior ( 627338 ) on Thursday May 31, 2012 @09:09PM (#40175247)
    at my 250k employee company with a bajillion servers and workstations, virtualization is mostly a work-around for the ancient and technophobic company policy of seperating servers by the individual application they run. All of my department's server side stuff (except the database) can easily be run on one box with one active/active failover box in a different location. This is how it was demo'd, benchmarked, vetted, and tested. Corporate audit went ape shit that we had an APPLICATION SERVER that was also SERVING UP WEB CONTENT!!!!!!!!! Fast forward 8 years and we have THIRTY TWO virtual servers in EACH ENVIRONMENT (production and fail-over). All doing the job of one decent server, and realistically all together taking up one server's worth of hardware (but with much more OS overhead BS than just using the one stupid server for the various applications.

    So basically we pay some VMWare licenses, 62 extra windows licenses, some hefty maintenence contracts, and who knows what else in order to use the server in the way that the software originally was intended to run (1 box for all the apps). Nice workaround for braindead company policy.

    Honestly, other heavily virtualized shops that I have seen were mostly the same thing.

    Virtualization in the business world is really just a work around for the fact that computers got more powerful faster than they were able to gain trust and confidence of senior management.
  • by Alex Belits ( 437 ) * on Thursday May 31, 2012 @09:11PM (#40175267) Homepage

    Virtualization is a stone-age technology, useful for crippling hostile environments. This is why "cloud" providers love it, and developers use it for testing. Incompetent sysadmins use it in hope that they can revert their mistakes by switching to pre-fuckup images, having this strange fantasy that this shit is going to fly in a production environment.

    If you REALLY need separate hosts for separate applications in production environment (what you almost certainly don't in presence of package manager and usable backup system), there is host partitioning -- VServer, OpenVZ, LXC-based environments, up to schroot-based chroot environments.

  • by Zocalo ( 252965 ) on Thursday May 31, 2012 @09:21PM (#40175351) Homepage
    +1 This. The situation is a lot better than it used to be, but VM software tends to have a problem with keeping an accurate clock and that can bite you in some interesting ways, such as:
    • Pretty much anything to do with authentication; that means Active Directory, Kerberos and LDAP for sure, and depending on your setup might also include backends hosted in those systems such as AD/LDAP integrated DHCP/DNS if you have short TTLs.
    • NTP servers. Just don't go there. It should be obvious why, given the statement above!
    • System logging - you can forget about having accurately time synchronised system logs on VMs. The best solution here is to send all your VM logs to a central server and make sure the timestamps come from that server and not the remote one. Needless to say, this also needs to be a physical machine.

    In addition, it should be pretty much a no-brainer that anything that tends to saturate I/O, whether that's CPU, disk, network or something else generally doesn't play well with co-hosted VMs when it's doing its thing, things like number crunchers, database servers, busy web servers and so on, all need to be evaluated on a case-by-case basis.

  • Re:Busy databases (Score:4, Interesting)

    by swb ( 14022 ) on Thursday May 31, 2012 @10:06PM (#40175657)

    At most places you don't get to buy SAN often enough or large enough to have the luxury of allocating a dozen spindles to three RAID-10 sets. Eventually management's store everything spend nothing philosphy causes those dedicated RAID-10 sets to get merged and restriped into the larger storage pool, with the (vain) hope that more overall spindles in the shared pool will make the suck less sucky.

    In that kind of situation, it's not always crazy to spec a big box with a dozen of its own spindles for something performance oriented because you can't be forced to merge it back into the pool when the pool gets full.

  • Re:Busy databases (Score:4, Interesting)

    by NFN_NLN ( 633283 ) on Thursday May 31, 2012 @10:34PM (#40175823)

    Couple of corrections. HA (high availability) works without vCenter, if a host running vCenter dies HA will restart it on another host like any other VM. A vDS will continue to function you just can't connect VMs to the distributed switch.

    You are correct, it is only the ability to reconfigure HA and vDS that is lost with vCenter. Loss of vDS would be critical to the operation of VMs.

    I have never actually run vCenter Heartbeat. They effectively make you pay for 2 copies of vCenter and 1 copy of heartbeat. I've had customers interested... until the price comes up. Can't say I disagree.

  • Re:Busy databases (Score:4, Interesting)

    by houstonbofh ( 602064 ) on Thursday May 31, 2012 @10:41PM (#40175857)
    I posted this and everyone went "Vcenter!" But it could also be Vsphere (which was the case) or Xen management tools, or KVM management tools... In other words, don't make it easy to lock your keys in the car...
  • Re:Busy databases (Score:4, Interesting)

    by Cylix ( 55374 ) on Thursday May 31, 2012 @11:00PM (#40175975) Homepage Journal

    That is more of an issue of accounting.

    At a shop I used to work out we broke out the cost per spindle and that purchase had to be paid by the org that need the resources. Absolutely everyone and their mother wanted completely horrendous amounts of resources for every 2 bit project. However, since we were in the business of actually ensuring there was a return on the investment we had to enforce resource allocation.

    This translated to a few interesting things. Projects had to be approved and had to be assigned a budget. Resources were fairly well managed and projected utilization was also fed into the overall purchase. We could not actually purchase new hardware without funds and you can be damn sure we weren't dipping into our org funds to pay for someone elses project. If the PHB had enough power to say "do it" he also had the power to allocated resources.

    Probably the only thing that made any of this actually work were that budgets were real. ie, this is the cash you get to fund your project... don't waste it all on licensing or else you get no hardware. (I also said a few things) Head count was also tied to this resource allocation. We had man hours to apply to given amount of staff and the only way to get more help was to ensure budgets were enforced. We were pretty good about ensuring budgets were enforced from even the lowliest tech because over expense could very well end that lowly guy on the food chain. (Being consciously aware of these makes helps to turn your most ineffective resource into the most effective!)

    Now, I had one moronic group under-spec and over spend their budget. I had to knock on some doors, but I effectively managed to get them donated hardware from groups who way over-killed on budget planning. They were grateful and I brought costs down by not putting more junk on the dc floor. However, I sometimes think I should have let survival of the fittest win out there.

  • by tconnors ( 91126 ) on Thursday May 31, 2012 @11:03PM (#40175993) Homepage Journal

    Get nagios to monitor each VM, and each host (meh, not so important - only for esxi host logfiles), compared to the ntp server(s), and compare the server against a smattering of external hosts (perhaps including your country's official time standard if you're a government organisation). We're monitoring 250 VMs here, and none of them have ever been more than 0.1seconds out.

    I forgot to say: monitor against external ntp providers (asking Networks to punch holes through firewalls for your monitoring host(s) appropriately) even (especially) when using super expensive GPS clocks as your stratum 1 source. You have to remember that GPS receivers are manufactured by cheapest bidder incompetent fools who don't even understand how TAI-UTC works, hence why they're lobbying to abolish UTC time. Symmetricom, I'm looking at you. Good thing leap seconds are updated in the ephemerides at UTC=0, so on the east coast of Australia, are applied erroneously 3 months early when optical telescopes aren't observing the sky.

  • Re:Busy databases (Score:2, Interesting)

    by Anonymous Coward on Friday June 01, 2012 @08:45AM (#40178709)

    Here in the datacentre where I work, we have many VMs running of a PCI-Express SSD from virident and the performance is impressive. Really impressive, beating any other solution we've tried with SANs. We've sen two problems so far:

    a. Size of the SSD is small, so the amount of VMs is limited.
    b. It's not always easy to create a HA environment with two servers running these VMs. Scalability is also an issue.

    # lspci |grep Virident
    15:00.0 FLASH memory: Virident Systems Inc. FlashMAX Drive (rev 04)


"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972