How can I use virtualization in my new network

[reggiep]

Hurrah! It's April so I should get some money soon to replace our CC3 network with something else. While I'm at the planning stage I am concious that I know nothing about virtualization on the server side!

I run virtual machines for testing workstations and linux installs etc but never thought about the server side.

Can anyone suggest where virtualization may be something to think about when setting up a new network?

 

Thanks

[kmount]

What do you want to achieve? (How many roles/users/current servers/etc do you have?)

[tmcd35]

The primary goal of virtualisation, and financially the reason it is so popular, is server consolidation. How many servers do you currently have? How many are up for replacement?

 

If you have (i'd say) 5+ physical servers over about 3years old then you might consider buying 1 or 2 top spec modern servers to replace them with and run those machines as VM's on the new kit. It should - if done correctly - be cheaper than buying 5+ new servers to replace the existing kit and be still be faster than your existing servers.

 

Beyond that you get the benefits of easier physical server replacements/upgrades in the future. Easier to provision new servers as they are needed. Better disaster recovery - back up the virtual hard drives and use them to build new VMs on another box in case of HW failure.

 

Ultimately it's down to the size of your existing infrastructure. Where you feel things are go to change/expand in the future. And what you want to get out of the whole process.

 

At the end of the day if you only have 1 or 2 servers to replace virtualisation may not make sense. Every case is different.

[reggiep]

We have 2 admin and 2 curric domain controllers which we are combining into one domain and 300 ish workstations.

I was just wondering if I was missing the boat by having nothing virtual at the moment!

[Dos_Box]

I have my WSUS, Sophos and an SGD XP machine all as VM's.

[reggiep]

So do you guys just have something like VMWare running on a server with images running from that?

I like the sound of running Sophos off a virtual server DOSBOX

[tmcd35]

Currently I have no true dedicated virtualisation servers. I have a few installs of M$ Virtual Server 2005R2 running on standard Win2k3 physical servers. These run a handful of VM's which we are testing ready for the start of the great 'Hyper-V' migration which is due to start during the October half term.

 

When we are finished we will have 3 or 4 physical servers running Hyper-V and connected to a SAN. All our actual day to day production servers (file servers, print server, av server, apps server, dhcp, dns, etc, etc) will be virtual machines running on top of this infrastructure.

 

This is similar to the last place I was at who now (as memory serves) have 4 or 5 physical servers connected to the SAN all running either ESX or ESXi. All there traditional servers (about 17 of them at last count) run as VM's across them.

 

In your case @reggiep, If all 4 your servers are up for renewal then it may make sense to combine them into 1 or 2 new hosts and run them as VM's. Then you can look at spinning the likes of WSUS, DHCP, DNS, AV, etc of on to their own VM's.

 

If only 1 or two of the servers need replacing there may not be a whole lot to gain. You could just buy a cheap well spec'd server or workstation class PC to run M$ Virtual Server 2k5 or VMWare Server (the free ones that run on top of windows) and use this a test bed for virtualisation. Start small - perhaps virtualise your WSUS server, then dhcp/dns, etc.

[Dos_Box]

I just use Microsoft's Virtual Server on Server 2003 X64 R2. I also have the KS3 Testing server virtualised too

[PiqueABoo]

ready for the start of the great 'Hyper-V' migration which is due to start during the October half term.

 

I would seriously think about postponing that until Hyper-V Server 2008 *R2* hits the streets - it's supposed to address the features that got it an 80% score (versus VMWare's 100%) in the recent Burton Group report on virtualisation platforms.

[tsky]

I'm waiting for the budget to come through to go ahead with the virtualisation project we're undertaking. Currently have a couple VMWare servers doing odd tasks, but started going the Citrix Xen route.

 

Planning on having two Dell 2950's stacked with drives as SAN nodes with HA Failover between them, which will hold all my Xen images on an iSCSI container.

On top of that, about 3 of the cheapy R200 1U servers decked with memory for processing in an N+1 capacity for failover.

 

Currently have a lot of ageing servers that haven't been on UPS so their PSU's are all getting mashed and we've had to replace one PSU and one server due to the cackola power in the building. Part of the budget is nice rack n rackmount UPS to go with the new servers.

 

If you're planning on complete new network, just consider what you want to achieve - we're going virtualised because we need to reduce number of out of warranty servers, increase speed in rebuilding / rebooting (trust me.. you don't want to have to reboot a Dell 4400 from cold uuurgh). It's also proving to be a good time to look at it for us ahead of the BSF. We're pushing forward with new initiatives to prove that the skills are available in-house and that by doing things ourselves and consolodating NOW we can have cost savings over the next few years, deploy half the things county said were impossible and provide better facilities for staff and students.

 

[Ric_]

I will be giving an overview of virtualisation technologies and its uses at the May conference - not long to go now

 

Although I would agree with tmcd35 about consolidation, 'high availability' (HA) is also a top reason for virtualising servers. For instance, your current DC explodes in a ball of flames... you need to order a new server, set it up, test it and then make it live. With virtualisation, you automagically failover to a second box.

[flyinghaggis]

Agreed failover/redundancy is probably the main reason for virtualising servers IMO. Means you no longer tied to physical hardware in the event of a fault.

 

Another benefit of this is that it makes service packs and other major upgrades a far less stressful task. Mainly because you can take a snapshot of the server image pre-update, apply the patch and if it goes horribly wrong for any reason you just re-mount the old image before you tried the update! If you did the above with a locally installed OS on a server you'd probably end up spending a whole day trying to recover from backup!

[PiqueABoo]

'high availability' (HA) is also a top reason for virtualising servers

 

True, although bear in mind that part of Hyper-Vs missing 20% is because it doesn't do "live migration". Your HA VM from the expired physical server is *started* on another member of the failover cluster i.e. it doesn't carry on in whatever state it happened to be in a little while ago.

 

Not a major issue for me for failover, but for maintenance etc. I'd definitely like to be able to move a VM to another physical host without any particularly appreciable downtime.

[tmcd35]

True, although bear in mind that part of Hyper-Vs missing 20% is because it doesn't do "live migration". Your HA VM from the expired physical server is *started* on another member of the failover cluster i.e. it doesn't carry on in whatever state it happened to be in a little while ago.

 

I thought some clarification of HA and Live Migration would be helpful here as this sentence is a bit ambiguous.

 

High Availability - The ability to *restart* a VM on another host if the current running host dies. This does not use and has nothing to do with Live Migration. If the host dies then so does the running VM. HA detects the VM has stopped running and restarts it on another host.

 

Live Migration - The ability for the end user, or a load balancing program, to move running VM's from one host to another. Both hosts need to be up and running for this to work.

 

In both cases both hosts need access to the volume the VM is stored on - either NFS/SMB share or SAN LUN via a clustered file system.

 

In order of importance, I'd say, Server Consolidation is the primary reason for virtualisation followed by Disaster Recover then High Availability. Live Migration is useful but as a feature way down the list of importance for me.

 

As for Hyper-V I'm aware of the failing of the current version and the features promised by v2. If 2008R2 isn't released by October this year I'll be purchasing 2008R1 with Software Assurance and upgrading the server on 2008R2's release. The plan is to have the servers virtualised running 2008R2 DataCenter in time for deploying Windows 7 in (probably) 2011.

[superfletch]

I will be giving an overview of virtualisation technologies and its uses at the May conference - not long to go now

 

 

I feel like I should know more about this conf', where, when, and how do we book?

 

Is the whole conf' aimed at virtualisation tech or just the section you're doing?

 

Cheers,

[Ric_]

I feel like I should know more about this conf', where, when, and how do we book?

 

Is the whole conf' aimed at virtualisation tech or just the section you're doing?

 

Cheers,

 

Only my section is on virtualisation... there will be other stuff too.

 

By the end of the Easter break we should have the full details for you all and a lovely booking form - this will give you over a month to work out travel arrangements and accomodation.

[DMcCoy]

I will be giving an overview of virtualisation technologies and its uses at the May conference - not long to go now

 

Although I would agree with tmcd35 about consolidation, 'high availability' (HA) is also a top reason for virtualising servers. For instance, your current DC explodes in a ball of flames... you need to order a new server, set it up, test it and then make it live. With virtualisation, you automagically failover to a second box.

 

We don't actually use HA, having only a VMware standard+vmotion license.

 

There are lots of other reasons though:

 

Templates

Hardware independence for servers

Server Maintenance (bios updates and patches etc)

Multiple OS types on a single machine

Important roles spread out to reduce impact of patching/reboots of VMs

 

To instantly fail over (not just automatically start on another server) without service interruption you would still need something like MS clustering etc.

 

I've been reading up on Microsoft's solution to the lack of a cluster file system for R2, and what I've read makes me highly sceptical about R2s Hyper-V implementation, which is a shame as I would like to move to it when I finally have servers that support it!

[Theblacksheep]

To instantly fail over (not just automatically start on another server) without service interruption you would still need something like MS clustering etc.

 

I've been reading up on Microsoft's solution to the lack of a cluster file system for R2, and what I've read makes me highly sceptical about R2s Hyper-V implementation, which is a shame as I would like to move to it when I finally have servers that support it!

 

In ESX 4 (which I think is due to release in two weeks), hey, people are talking about MS features that wont be available for a year, so a few weeks is also ok! There a new feature called VM lockstep where two VMs run at the same time, if one fails the other becomes the live copy. I'm not sure at which level the service get introduced though.

 

I'd like to add that DRS and power managment is another quite important VM feature, not top of the list, that is missing from the MS implemention. Dynamic filtering of where to start VMs in the event of failure or in the case of hot cloning for VDIs, starting and moving the VMs around host depending on load. Even moving VMs to one host at night when load is low and shutting down other hosts for power saving/maintenance.

 

Moving storage while the machines are live is also a pretty good feature.

 

Transparent page file sharing and ISO instancing are another two examples that are not too important when you dont have it, but add a little extra to server and space consolidation when you do.

 

 

 

Yet another disk died on our RM exchange server the other night, so I P2V it... increased the C drive space from 8GB (pathetic) to 16 and it was running again in 6 hours.

Edited April 8, 2009 by Theblacksheep

[superfletch]

By the end of the Easter break we should have the full details for you all and a lovely booking form - this will give you over a month to work out travel arrangements and accomodation.

 

Any info on those dates available yet?

 

Cheers,

[SpuffMonkey]

 

In both cases both hosts need access to the volume the VM is stored on - either NFS/SMB share or SAN LUN via a clustered file system.

 

 

As someone who is just about to dip their toe in this somewhat muddy pond - what's considered the best way of locating the VMs - do you run ESXi on the physical server and keep the VMs on the SAN? Or run ESXi & the VMs on the physical server, but locate your data/backups on the SAN? Be interested to hear what people do.

[tmcd35]

The VM's belong on the SAN. The VMFS formatted LUN that the VM's are stored on should be visable by all of your ESX/ESXi servers. This way, If one of the servers are taken out of action for a while, all the VM's normally controlled by that server can be quickly and easily restarted on any other server, if memory and processor allocation allow.

 

For this reason I don't normally recommend, in day to day use, provisioning more than / of the total capacity of each server.

 

So if you have 3 servers - you'll use 2/3rds of their total capacity. If you have 4 servers it'd be 3/4 of the servers capacity used. This way if 1 server goes down you are more than likely to have the space accross the other servers to run the effected VM's.