Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Barriers to Virtualization Expand / Collapse
Author
Message
Posted Saturday, June 13, 2009 12:22 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Yesterday @ 9:53 AM
Points: 569, Visits: 985
Comments posted to this topic are about the item Barriers to Virtualization
Post #734410
Posted Saturday, June 13, 2009 12:39 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, February 20, 2013 2:23 PM
Points: 254, Visits: 131
When you say "commit crimes" I presume you mean take risks. A "good IT project manager" isn't going to commit crimes... we take risks every day.

The director of infrastructure where I work asks the question "what have you saved me this week?".

It goes deeper than the weekly question. Every employee has annual written goals, reviewed and revised bi-annually, that include an acknowledgment of commitment to saving money. Our annual bonuses are based on this along with other factors. It's a culture thing, and everyone is involved.

Saving money is paramount; risk taking minimized, and crimes, well, not committed.

During 14 years in the Pentagon, it was often noted that we spend more time in front of the vending machine buying a 50 cent candy bar than we do when spending hundreds, if not hundreds of thousands, of dollars – taxpayer’s money.

Perhaps that's a crime in itself?


Thanks,

David Russell
Oracle Since 1982
SQL Server Since 1998
Post #734418
Posted Saturday, June 13, 2009 4:57 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, December 14, 2010 4:03 PM
Points: 164, Visits: 143
I think many of the things you noted are good arguments FOR going virtual. It provides a layer of hardware abstraction, so with a virtual machine, moving it from one physical piece of hardware to another is most often a heck of a lot easier and faster. The same goes for making a compete 'copy' of a system if needed for testing, a staging environment, etc It might make the initial transition a little more difficult, but once you are running VM's you've got a lot more freedom to do things like take snapshots prior to deploying updates (and rollback in a matter of seconds if things go south) or move the vm from one physical system to another.

Admittedly this is a bit trickier with Vm's where performance is paramount that are likely to use direct access to their data drives instead of using virtual hard disks. In that case you might need to move the physical drives or make an image of them, instead of just copying a single file or directory from one system to another. But it's still a lot easier to deal with moving the VM from one system to another due to the more generic hardware that the virtualization system emulates.

Not to mention that relatively simple tweaks such as allocating another processor, or more memory, can literally be done in seconds of time. It will take longer to shutdown and startup the system than it will to change the VM settings to allocate more memory or another CPU. Other changes like allocating another network card, or creating a private vlan within the host server can be done on the fly.
Post #734459
Posted Monday, June 15, 2009 6:56 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, April 14, 2014 6:37 AM
Points: 58, Visits: 442
The one factor that I seem to run into when considering the move to virtualization is that it will cost more in things like storage area networks and high bandwith switches than I would gain in reduced server costs. I just haven't seen where it will benefit us.


Post #734953
Posted Monday, June 15, 2009 8:07 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 14, 2014 1:45 PM
Points: 23, Visits: 303
I'm kind of with Grasshopper on this. We have a few dozen servers, all with direct attached storage. To go virtual, and really take advantage of high availability and disaster recovery, we would require some kind of network storage. The recommendation also seems to be to go with servers that have virtualization built into them, which means our existing servers will be retired. All of this means we would need to invest significant dollars in hardware.

The argument of going green falls on deaf ears around here. As a manufacturing facility we have machines that use enormous amount of electricity which dwarfs what we consume in IT. I realize every little bit adds up, but the argument just doesn't get very far with top management.

All of this being said, we will eventually virtualize our server environment. We will start with some of the easy ones like DNS, DHCP and file/print. Our core ERP system will probably be the last one to be virtualized, and it is the one that would benefit the most in terms of high availability that virtualization would offer.

I'd be interested to here from folks who have virtualized some of their large, core systems.
Post #735030
Posted Monday, June 15, 2009 3:03 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, December 14, 2010 4:03 PM
Points: 164, Visits: 143
dld (6/15/2009)
The recommendation also seems to be to go with servers that have virtualization built into them, which means our existing servers will be retired. All of this means we would need to invest significant dollars in hardware.


More than a recommendation, this is required by most serious (e.g. secure, stable, high performance etc) virtualization platforms. I know it's a requirement for Hyper-V.

Then again, most 'server' class cpu's made in the last few years have the hardware virtualization stuff built in. So yes, you'd not be able to retask truely "OLD" hardware for this, but anything fairly recent ought to work.

Power savings might not be enough to make a big dent on the power bill for the entire company, but it could offset a fair portion of the cost for a new server, especially when you consider the multiplication effect of not needing as much AC for the server room, (or pushing what you have closer to it's limits) UPS capacity etc.

I think it's something that makes a lot more sense to sort of slide into as you are looking at replacing hardware, retiring older boxen etc.

Another potential benefit is replacing older legacy servers that you know are on the far side of the MTBF curve, and are existing on borrowed time. Unless you have a need to update the OS or other software for security reasons, it's not too hard to migrate a system like that onto a VM, one that doesn't need a lot of resources from its host.. literally moving the system (using utilities that make it easy) or just doing a backup and then restoring onto a basic VM of the same OS the old system is using).

sorry, I'm up on my Virtualization soapbox. I'll get down now. (just be glad I didn't get into using VM's for test environments.. they really rock for that)
Post #735334
Posted Monday, June 15, 2009 3:24 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 14, 2014 1:45 PM
Points: 23, Visits: 303
SQAPro (6/15/2009)
[quote]dld (6/15/2009)

Another potential benefit is replacing older legacy servers that you know are on the far side of the MTBF curve, and are existing on borrowed time.


Thanks for the input. We do have a few older workhorse Sun servers, one of which used to run an Oracle DB, but now sits idle most of the time - running a few perl scripts from cron. These will most likely be our first VM targets.
Post #735340
Posted Monday, June 15, 2009 4:48 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:49 PM
Points: 32,768, Visits: 14,929
I don't think I'd advocate trashing existing systems and moving to VMs for many people at all. Instead I'd start learning about it, and perhaps shifting some systems to VMs for the practice, and then considering virtualization for new installations.

I rarely see fewer servers in companies, but with virtualization, you can slow the growth from new physical boxes. And as you get practice, you might move some of those older systems, as their hardware becomes a problem or you want to get rid of it (say for new server space).







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #735370
Posted Tuesday, June 16, 2009 10:56 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: 2 days ago @ 4:56 PM
Points: 8,271, Visits: 8,717
Suggesting that "Simple servers, such as DNS, DHCP, or Active Directory Servers" are going to be easy for virtualisation seems to me a bit strange. Anyone who has to live with the error rate inherent in having DHCP dynamically updating DNS with zones held in Active Directory will probably have written a "DNS-DHCP reconciliation tool" to fix the numerous discrepancies and concluded that this service collection is far from simple and maintenance free. Also, in many environments these are mission-critical services and putting the out in a cloud somewhere where you don't have instant control is maybe not such a good idea.

DHCP needs to be very fast and relkiable in some environments - if it's off at the far end of a slowish pipe it won't be useful, nor weill it if the pipe is unreliable. Same for Active Directory - particularly kerberos (user validation/login) and applying group policy (if I never again see event 1030 in a Windows system event log caused by network issues I'll be a happen man).

For the majority of people, a decision to virtualise the DHCP service is clearly a manifestation of CTD in a non-database sphere! How much server power will you save? How much network cost will you incur? I don't think there's any saving to be made, in fact I'm pretty sure that it would be a pointless and expensive exercise.

The real barrier isn't porting ones own proprietary applications into the cloud - it's coping with poorly written software provided by third parties. Getting one's own application structure cleaner and more hardware independent is something that's good to do anyway (it gives us some extra flexibility and future-proofing) so the need for that is not the real barrier.


Tom
Post #735853
Posted Tuesday, June 16, 2009 11:16 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:49 PM
Points: 32,768, Visits: 14,929
DNS and DHCP servers do need to respond quickly, but they have low resource requirements, and I've seen many people virtualize these easily.

Going to a VM doesn't mean your server is off in some cloud. It's often on a box in your same data center, same connectivity. It's just not occupying the whole box.

File and print servers are good places to start learning, they can tolerate some delays, and you'll get an idea of complaints or comments from users.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #735871
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse