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 Tuesday, June 16, 2009 12:05 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, November 20, 2014 8:17 AM
Points: 24, Visits: 335
Our file and print server will probably be our first production VM.

Being in a manufacturing environment means I have to be very careful about anything that will interrupt the plant process. Down time in the plant means many $$ per minute. Having said that, the IP connected equipment in our plant all has fixed IP addresses. That doesn't mean DHCP is not important, but it would not bring us totally down.

I would also second Steve's observation, that reliability and speed does not need to be compromised in a virtual environment. Done right, with appropriate hardware, virtualization can rival a dedicated hardware server.

As far as the "Cloud" goes, putting data into a public cloud environment may have its place, but not for core operating systems.
Post #735910
Posted Tuesday, June 16, 2009 10:04 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
Tom.Thomson (6/16/2009)
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.


who said anything about cloud?
Lets be very clear here: Virtualization <> Cloud

I'm referring to running multiple virtual machines (VM's) on a virtualization platform such as Hyper-V or VMware.. something that works particularly well for servers that sit around idling at like .1% cpu capacity for 98% of their lives.

The reference to 'simple' was to the physical requirements (cpu, memory, disk, etc) of the systems, NOT with reference to configuration. If a service is tricky to configure, that's not going to change, it stays tricky. Using a VM can't really eliminate that pain. OTOH even in this regard there are some benefits, such as making a copy of a properly configured system becomes a cinch. copy a few files (or 'export' the machine) on the host system and you're done. Also if you want to tinker with settings for any reason, Saving a 'base' state as a 'snapshot' in Hyper-V takes seconds, It literally takes me longer to figure out and type in the name for the saved state than it does to create the snapshot. Then I'm free to try some alternate settings, and if it didn't work, or made things worse, I can revert back to the snapshot in a matter of seconds. If things work better I delete the snapshot and move on.

(note for something like DNS/DHCP etc you might want to snapshot the system in a shutdown state, since if it's running, it is restored to a perfect copy of the current state when you took the snapshot with the exception of a very few things like the realtime clock. which might not be such a good thing if the snapshot is from a day or two ago, and you'd be restoring a bunch of obsolete in-memory data on leases etc if you reverted back to the 'as running' state.

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.


agreed, the 'cloud' is not the place for this kind of system, or anything else where latency is an issue. but as we said before Virtualization <> Cloud

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.


CTD? ok you've stumped me, Circling the Drain? Close to Death? Cheaper Than Dirt? what's your meaning here? I hope I don't have to take points off my geek score for not knowing this.

Seriously, again I think you are confused with cloud vs virtualization. but here's a real world example for you. I run some 20+ (and growing as the need for new configs arise) testbed systems (win2K, XP, 2003, Vista, 2008, 32 and 64 with or without SQL 2000 (MSDE) SQL 2005, SQL2008, IIS of various vintages), all off a single dual quad-core 2U high rackmount server. So what's my power savings vs having 20+ physical systems (or a smaller number and constantly having to juggle what's installed where and tons of disk images) Especially if we are talking older power hungry systems like P3 and P4 systems that didn't have speedstep type tech to lower the power when idle? Oh and the power for monitors, kvms, etc also. vs the one server, and little vista desktop that I used to access console sessions on the vm's (I manage them and the host remotely, server room is 300' from my desk but I have set foot inside in nearly 3 months time)

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.


Agreed. OTOH once you have a system setup as a VM, it IS running on what it considers to be very generic hardware. So cloning the system, or moving it from one physical host to another, becomes childs play. Yes that does get complicated somewhat by big disk arrays, SAN's etc which is one reason to start with the simpler (hardware wise) systems, get experience there, and then evaluate if it makes sense for your more sophisticated (hardware wise) systems.
Post #736188
Posted Wednesday, June 17, 2009 3:32 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:45 AM
Points: 7,860, Visits: 9,606
SQAPro (6/16/2009)
[quote]Tom.Thomson (6/16/2009)
CTD? ok you've stumped me, Circling the Drain? Close to Death? Cheaper Than Dirt? what's your meaning here? I hope I don't have to take points off my geek score for not knowing this.


Sorry, I should have written it in full: CTD = Compulsive Tuning Disorder - - the horrible syndrome suffered by too many DBAs and SysAdmins and developers (and System Architects) that makes them too busy burnishing the pine needles to notice that there's a forest-wide problem. The term has been around in database circles for 8 or 9 years I think, coined by Vaidyanatha who wrote books on Oracle so maybe better known in Oracle circles than in SQL Server circles.



Tom
Post #736314
Posted Wednesday, June 17, 2009 4:02 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:45 AM
Points: 7,860, Visits: 9,606
Steve Jones - Editor (6/16/2009)
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.


But what is the point of virtualizing these things? It doesn't save any hardware or software or configuration or backup or recovery planning or anything else that I can see.

Already in a typical small sized installation of our system the AD, DNS and DHCP services will be running on the same physical server as the active databases, websites, and application services. Assignment of discs (or actually arrays) to various functions is no more complex that assignment of them to VMs, so there's no saving there. The only thing that virtualization of these three servicers might help with is that maybe I could have the databases in a VM that doesn't contain AD, and not have to worry about NTBackup screwing up the chains of DB backups - but that would require me to refrain from taking system backups of the virtual machine handling the databases, so no thank you very much, I'll live with having to properly mesh the backup schedules and having only short chains!

As the systems get bigger and more heavily loaded, there will be extra servers. All of them will run all the software, all the services except that DHCP will run only on one of them at any time. Virtualization doesn.'t appear to help there either.

I have serious uses for virtualization, but not for this sort of stuff. In development of embedded systems (clients, not servers) I really want to have a nice big engine that does builds and interfaces to the source control service and the release service and so on, but (a) I don't want to have to move to a different machine for testing and (b) I have to run the hardware discovery build on the target machine not the hefty build machine; so having a build VM and a hw discovery and test VM (and maybe a separate debug VM) all on the same hardware is extremely useful. Maybe source control and release management and software configuration control for the embedded system will be in VMs on the same hardware too. Maybe teh server I test the embedded app against can be another VM on teh same hardware. Putting large scale services onto VMs in a production environment can make sense too, but surely hiving off things like DHCP, DNS and AD onto separate VMs is more trouble than it's worth?


Tom
Post #736328
Posted Wednesday, June 17, 2009 7:20 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:16 PM
Points: 31,284, Visits: 15,748
AD is distributed, living on multiple servers, so I'm not sure what you're getting at with the AD database.

Lots of people do run DNS/AD DC (domain controllers), and DHCP on the same box, but there are a few of them. In one environment, we had 4 or 5 DNS servers (not dedicated) and over a dozen DHCP servers. Add in print servers and file servers, and we can easily be talking 2-3 dozen servers in a large environment.

We use VMs? Part of that is being able to separate off services to separate Windows instances, perhaps for compatibility, perhaps because departments want their own server (political reasons).

As you move to dedicated machines for certain functions, say an app to handle door security, maybe one for network config software, maybe one for filtering software, you can end up with a profilferation of machines that don't really need a full physical server, but require separation from other apps for some reason. Might be as simple as an ignorant vendor that won't provide support unless it's on it's own Windows instance.

VMs make sense. Not everywhere, and not for all production systems, but they make sense.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #736522
Posted Wednesday, June 17, 2009 9:21 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 12, 2014 8:26 AM
Points: 66, Visits: 525
I know for me, the biggest excitement that I get from the VM world is when we start talking about testing. Being able to clone my production server and then apply version updates to the clone is where I get all the warm and fuzzy feelings.




Post #736701
Posted Wednesday, June 17, 2009 9:32 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:16 PM
Points: 31,284, Visits: 15,748
Don't forget that cloning doesn't mean you ignore data safety/control issues. Keep that production data safe! Even in test VMs.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #736718
Posted Wednesday, June 17, 2009 11:38 AM


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
Steve Jones - Editor (6/17/2009)
Don't forget that cloning doesn't mean you ignore data safety/control issues. Keep that production data safe! Even in test VMs.


++

sanitize scripts are a must! Also remember to nuke log-files or anywhere else PII or other sensitive info might reside.

You also need to remember the clone will have the same system name, fixed IP if assigned, etc. So bring it up in a private network (easily facilitated within the host system on most virtualization plaforms) or 'off' the network entirely, (controlled from VM settings, no need to go 'pull the net cable' physically) and change those values so you don't conflict with the system the clone was made from.

Regarding testing... I could go on for a long time.. VM's absolutely rock for testing. I've gone entirely virtual for this, and I never want to go back to physical machines unless there's no way around it.
Post #736837
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse