Showing posts with label Microsoft. Show all posts
Showing posts with label Microsoft. Show all posts

Thursday, September 3, 2009

Hyper-V Live Migration

Well Microsoft Hyper-V has been around for a little while now and has been playing the catchup game. However the release of Server 2008 R2 sees the introduction of features previously only available from other vendors.

One such feature is Live Migration, the ability to move a Virtual Machine from one Host to another without turning the guest off. Coupled with a case study deployment of Direct Access I got the opportunity to complete an implementation of Live Migration with great success.

Things I have learnt;
  • There's a lot of useless information around for Hyper-V - I'll try not to add to it :)
  • Hyper-V and Hyper-V R2 are quite different, dont expect them to behave the same.
  • DO NOT team network cards - As of today (04/09/09) teaming is not supported, and when it is, it will be up to the vendor to provide and support any teaming of NICs.
    Update: This has changed. Check this post for details.
  • You'll need more NICs - Hyper-V loves network cards. 2 teamed for production (when it actually works), 1 for heart beat, 1 for live migration traffic and 1+ for iSCSI, if you use it.
  • You'll have to rethink your SAN - Cluster Shared Storage require a witness disk for the quorim data, and you can't store anything else on it. So plan to setup a new vDisk from your SAN at around 250 -> 500MB.
  • You'll want more resources - One of the really appealing aspects to Live Migration is the ability to setup an N+1 High{ish} Availability Cluster, but that means the nearly 90% utalization you are currently running your poor, innocent hosts at, isn't going to do. Plan / Budget for it.
Server 2008 core

It is a huge pain. I do like working on core though, it feels (excuse the pun) hard-core, but it does make managing the hosts hard. Unless you are going to implement Virtual Machine Manager (which I do recommend btw) you aren't going to be able to do all the thing you want to within core. Troubleshooting is also made substantially harder.
The big appeal is of course the smaller footprint Core has - though dont expect some magic performance boost by just going to core.
That being said, I'd implement Hyper-V on 2008 Core whenever I can - it just seems appropriate.

As for your guests - You'll need to re setup their networking, moving to R2 will install new networking hardware with nice fresh DHCP settings [maybe an oversight from Microsoft but no biggie]. Just remember to record them before hard.

Micosoft Cluster Shared Storage

I've kept this seperate as it is required by Hyper-V Live Migration but IS NOT part of Hyper-V.
This means you should consider it seperately and carefully.

You'll need a static IP and hostname for your Cluster when you create it, you'll need to configure the Witness disk mentioned earlier and you'll need to seperate the heart beat, production and Live Migration network all setup in Cluster Manager.

TIP: Moving an already NTFS formatted disk to Cluster Shared Storage does not destroy the data. Be sure you have backups though.

Installation Order

Do things one at a time and test them carefully and you wont go wrong. - Measure twice, cut once and all that.
  1. SAN - Create the Witness Disk, Virtual Machine storage, LUNs etc
  2. Server 2008 R2 - Install the base OS, if at all possible stick with the Windows Drivers (I'd only use vendor drivers after careful testing) *See below for Core
  3. Networking - Assign your IPs, Name your NICs, test connectivity between all hosts and SAN [iSCSI]
  4. Storage - Connect to the SAN, check all the drives appear and make sure they have the same drive letters on all hosts.
  5. Clustering - Install MPIO and Clustering. Create your cluster, give it its IP and hostname, check your hosts and networking appears corrently. Configure your witness disk.
  6. Hyper-V - Install Hyper-V, configure all networking, dont create Guests!
  7. Live Migration - Enable Cluster Shared Storage and add your disks (No, not the witness disk)
  8. Add/create your Virtual Machine using Cluster Manager.
  9. Check their configuration using Hyper-V manager.
  10. Start your Guests using Hyper-V manager.
  11. Migrate your Guests using Cluster Manager.
Well thats all for now, have fun with Virtualization. It's powerful technology but there's a lot of room to break things, so please be careful.

Footnote about Server 2008 Core:
There's a lot of good info online about the basic setup of core as well as a few mini GUI tools to download. Check out http://www.petri.co.il/configuring-windows-server-2008-networking-settings.htm
One thing I'd recommend is get remote management working and do as much as you can from your Windows 7 management machine.

Update: As for this past weekend (12/10/09) I've managed to get NIC teaming working with Hyper-V. Have a read.

Tuesday, August 25, 2009

Microsoft Direct Access

Microsoft Direct Access has just been released and there is always a lot of hype with new solutions. However this one has truly impressed me and I hope to see some serious market uptake.

I recently had the opportunity to assist with New Zealand’s first production implementation of this, in conjunction with Microsoft Prof Services and I'll try to detail the experience below.

The first thing you need to know is that Direct Access is awesome, but comes with some friends. Like the hot blonde you're excited to let into your party, until you see the not-that-hot friends she's bringing too.

In this case I'm referring to IPv6 and Public Key infrastructure (PKI). Both technologies have very nice personalities, but they are a lot of work and aren't good looking enough to sell to your boss. If you create a plan to get these technologies in place properly, in addition to the Direct Access planning, you'll do fine.

Public Key Infrastructure

If you dont already have one, put it in place. It's useful in many other places too.

The catches;

  • Whatever server to decide to make your Certificate Authority will be with you for a long, long time. Virtualize if possible and choose a smart name.
  • Lots of certificates will be handed out - things like DCs are going to jump on the PKI bandwagon straight away. That’s OK, it doesn't hurt. It will only hurt if you start trying to be clever and stop them.
  • Server 2008 R2 - if you can, make it your CA. Newest templates and distribution points out of the box are nice.

For Direct Access use you will have to publish a CRL to the outside world. If you happen to have an ISA box, a web publishing rule is an easy option. But as long as you can get to the CRL how you do it is up to you. And no, you can’t reuse one of the DA boxes external IP addresses.

IPv6

It's coming and you can't ignore it anymore :) That being said there an army of technologies to make getting IPv6 going easier (and ironically, more complicated)

The one we are particularly interested in is ISATAP. Short version is it creates a IPv6 addresses based on [Address type][network prefix][IPv4 address].

In our case it would look something like 2002:0000:0000:0000:0000:5efe:192.168.1.1 or 2002::5efe:192.168.1.1

What you need to know is;

  • Any server taking part in the Direct Access communications will need one of these ISATAP addresses.
  • This is supported on Server 2003 and up.
  • The address is generated by doing a DNS request to ISATAP.{domain}
  • ISATAP.{domain} is blocked by default on your DNS server and will need to be allowed.
  • You can bypass this lookup, by configuring the address this resolves to, directly on the ISATAP interface, on the server you are configuring. (NETSH INTERFACE ISATAP SET ROUTER {ipv4 address of DA box})
  • You can disable and re-enable this interface to force it to do this DNS query again.

If you are doing IPv6 just for Direct Access the best results have been from leaving ISATAP blocked on your DNS servers and manually configuring the router address on the servers you want to take part in Direct Access. This leaves your other servers unaffected. Up to you though.

Direct Access

The irony of this name shouldn't escape anyone, this access is about as tunnelled as it gets. Packets get packaged in other packets, NATs traversed and the like.

Before you install you should read this. Lots of good info and instructions.

I'm not going to cover the install in details just the highlight and some tips I discovered. RTFM for the how to... and just 'cause you haven't downloaded it yet, click me.

  • 2 sequential Public IPv4 addresses both assigned to the same interface.
  • Un-firewall access to those IPs (OK if you have to, then check the guide for ports - but open it up for testing)
  • If you're doing it as a Hyper-V Virtual Machine use Legacy Network Adapters.
  • Use an IP Address, not a hostname for the Location Awareness URL (LAU)*
  • Get yourself an external IP for a Windows 7 client that you can stick in your DMZ - great for testing.
  • Enable your local admin account on your Windows 7 machines! - When things go wrong you will want to log in locally... and by 'things' I mean net being able to get ANY network comms.

The install of the Direct Access role itself and the configuration wizard are stupidly easy. The skill is in the planning, so be sure you do lots of it.

*Almost forgot. You'll want an IIS website hosted somewhere internal with a Certificate on it matching its IP address (and the PKI is useful again). You should be able to access this site securely and without any warning from the internal network, and not at all externally. The content of the site doesn’t matter, just that it exists. - This is how Windows 7 figures out if it's on the network or not. Location Awareness - pray it never gets it wrong.

Well, have fun and do me a personal favour. Do lots and lots of testing before giving this to your users. If we want this to be a hit in the industry the user experience has to be a good one. So let’s get it right and get people talking about it.

{Written while over Direct Access on Windows 7}