A job a day keeps the user at bay

There's always one isn't there? A pesky user who wants to try something fancy on a cluster but isn't entirely sure how to do it. This is the coal face of HPC. It might not have the glamour of procurement, or the technical challenge of system administration, but being able to help a stuck user is possibly the most rewarding part of the job.
I like to set myself a challenge every now and then (job a day? well, maybe not quite that often) to submit a job with crazy parameters, or oddball resource requirements. You never know when a user will want to do something similar, and then a) you'll be able to help, and b) you'll look pretty smart ;)
Thinking more about this I might fire in a blog post every now and than containing an interesting job submission technique, might be interesting to see if anyone can come up with any nifty alternatives...

Know your underlying infrastructure

So, you're looking to deploy and support a Windows HPC Server cluster, but you have a sneaky suspicion that there's more under the covers that you bargained for. What do you know, your instincts are correct, and you're suddenly in a world of Microsoft technologies which you should at least be aware of. 
The good news is (and this is a big advantage) that these underlying technologies are common, and it may be that your company/organisation has experience in those areas, for example in a corporate IT team. If those skills can be leveraged for your Windows HPC deployment, then it's all gravy - you can stick to what you do best & eke out tip top performance, and write some killer submission scrips for your cluster users.
But wait, what if you have no such skills in house? Well, here's a quick rundown of some of the things involved...


Windows Server 2008
The base Operating System. Note that Windows HPC Server can run on various editions of the OS (e.g. HPC Edition, Standard Edition, Enterprise Edition), which should show that the HPC Pack is a separate entity to the OS. License wise it's important to note that you can only run Windows HPC related technologies on 2008 HPC Edition - no chance of saving a few notes by using it as a base OS for your corporate Exchange system ;)
When thinking about the OS, pay particular attention to driver versions and settings. Use the built in reliability, performance & logging tools to your advantage.


Active Directory
There's no getting round the Active Directory thing. It's at the core of everything Windows HPC Server does, from deployment to running jobs to data authorisation. There are several potential options here depending on your environment. If you have a corporate AD I would strongly suggest that you work with your corp IT guys to integrate the cluster. This type of configuration will smooth the wheels of progress significantly. Allowing an existing authentication regime, one in which users already have accounts set up, can save a bunch of user admin overhead. If this is not an option, it's worth spending at least a bit of time pondering your AD architecture. It's nice and easy to simply promote your headnode to a domain controller, but I would suggest that you also run up another, separate Domain Controller, as losing your AD can be a royal PITA to recover from.
Either way, take some time to get this bit right, and to learn the basics of AD operation & you'll likely see payback in future.


SQL Server
I'm planning to dive into SQL Server a bit deeper in another post, but suffice to say it's well worth picking up some knowledge in this area.


Windows Deployment Services
WDS provides the platform for the super slick node deployment mechanism within Windows HPC Server. It's wrapped so nicely that you may never need to poke about under the covers, but definitely pay attention to imagex, diskpart, the \\<headnode>\reminst share and it's contents.


DHCP and DNS
OK so these are not necessarily Windows specific, but getting your DNS and DHCP knowledge down is very useful. I'm going to post about network configuration in another post, so will try to include some DNS / DHCP tips there too.


RRAS
Routing and Remote Access Services is an umbrella for bunch of useful Windows features. These include Dialup; VPN (both client server and site to site); IP subnet routing, and Network Address Translation (NAT). In the case of Windows HPC Server the NAT part is of interest. It plays an integral part in operation of those network topologies which rely on compute nodes only having connection to the private network. In these cases traffic destined for hosts on subnets other then the private network travel via the headnode (as gateway), and NAT out onto the enterprise network. This may be pertinent e.g. for Windows Updates and the like.


Windows Failover Clustering
If you're going for a High Availability head node solution, take some time to become acquainted with how Windows Failover Clustering works. Behaviour and types of shared disks; should you used disk share, quorum, node majority; Failover Cluster network configuration; Cluster resource DNS registration; verification and support of cluster components. This is a big subject in itself, and an awareness of how the technology works is important.

It's all in the name

I like names, they have a funny way of telling a story in a single word. Take my name for instance, I'm sure you read the word 'Dan' and assume that I'm a strong, intelligent, handsome guy who's no end of fun to hang out with, right? Or maybe it's the other way round, and the person defines your perception of a name. I mean, if all people named Dan are super cool, does that make the name Dan super cool?

Anyway, what I really want to talk about here is how Windows HPC handles name resolution, particularly across private and application networks.

First off let's think a little about general Windows host name resolution order. This looks like this, listed in order:

1. Checks it's own name.
2. Looks in the Local DNS cache (you can list entries using ipconfig /displaydns).
3. Local HOSTS file (C:\Windows\System32\Drivers\etc\Hosts)
4. Adds the Search Suffix configured on the machine (if not FQDN), and query DNS
5. WINS (NetBios name resolution)
6. Broadcast on local subnet
7. Local LMHOSTS file (C:\Windows\System32\Drivers\etc\Hosts)

Pretty thorough I'm sure you'll agree.

Now let's look at this with our high performance and management hats on. We want to be able to get an  answer to our name resolution queries as quickly as possible, while ensuring consistency across all nodes in the cluster. We also need to resolve a host name to the appropriate network address for the cluster network we're after. Running through the resolution order above we can ignore 1. for obvious reasons. 2. may be interesting performance wise,  but as the cache may not contain records for all nodes, it's an inconsistent choice. 3. hmmm, the good old local hosts file, sounds kinda antiquated and simplistic don't you think? But it's at number 3 on the list, crucially checked before DNS resolution. And maybe it can be managed by one of the HPC services running on all nodes? Oh, this is starting to sound decent. Just to be sure though let's continue. 4. is our old friend DNS, which sounds like the way to go. But each DNS lookup can take a relatively long time. Seems like it'd be good for management, but as good as a cluster managed solution? Once we get to 5, 6 and 7 things are drifting off into desperation, so let's not say too much about those guys.

Well what do you know, Hosts seems to be a very good choice here, and lo and behold that's how it works in practice! Check out this example hosts file taken from a handy dev cluster... 

# Copyright (c) 1993-1999 Microsoft Corp.

# 

# This host file is maintained by the Compute Cluster Configuration

# Management Service. Changes made to the file that match the netbios names

# for existing nodes in the cluster will be removed and replaced by entries

# calculated by the management service.

# 

# Modify the following line to set the property to 'false' to disable this

# behavior. This will prevent the management service from making any

# further modifications to the file

# 

# ManageFile = true

127.0.0.1                localhost

192.168.5.23             HPCDEV-HN02                    #HPC

192.168.100.11           HPCDEV-HN02                    #HPC

192.168.0.11             HPCDEV-CN001                   #HPC

192.168.0.10             HPCDEV-CN002                   #HPC

192.168.0.134            HPCDEV-CN003                   #HPC

192.168.0.1              HPCDEV-HN01                    #HPC

192.168.0.2              HPCDEV-HN02                    #HPC

192.168.0.3              HPCDEV-VHN01                   #HPC

192.168.1.1              HPCDEV-HN01                    #HPC

192.168.1.2              HPCDEV-HN02                    #HPC

192.168.1.3              HPCDEV-VHN01                   #HPC

192.168.5.22             Enterprise.HPCDEV-HN01         #HPC
192.168.5.23             Enterprise.HPCDEV-HN02         #HPC

192.168.5.28             Enterprise.HPCDEV-VHN01        #HPC

192.168.0.11             Private.HPCDEV-CN001           #HPC

192.168.0.10             Private.HPCDEV-CN002           #HPC

192.168.0.134            Private.HPCDEV-CN003           #HPC

192.168.0.1              Private.HPCDEV-HN01            #HPC

192.168.0.2              Private.HPCDEV-HN02            #HPC

192.168.0.3              Private.HPCDEV-VHN01           #HPC

192.168.1.11             Application.HPCDEV-CN001       #HPC

192.168.1.10             Application.HPCDEV-CN002       #HPC

192.168.1.134            Application.HPCDEV-CN003       #HPC

192.168.1.1              Application.HPCDEV-HN01        #HPC

192.168.1.2              Application.HPCDEV-HN02        #HPC

192.168.1.3              Application.HPCDEV-VHN01       #HPC

This file reflects the current addressing of a HA head node cluster configuration which has three compute nodes. Network topology is 3. Compute nodes isolated on private and application networks. Interesting to note that only the active head node addresses are detailed in the standard format listing (HPCDEV-HN02) for networks other than private and application (in this case Failover cluster heartbeat network and enterprise).

Check out those funky Enterprise. Private. and Application. entries. This allows the cluster service to be very specific in its address resolution requests, assuring it will always get back the address on an appropriate network.

But what if you want to host non HPC Server managed machines on your private network, therefore requiring hosts to register in DNS (they do not by default)? Well, you can use the awesomeness that is powershell...

Set-HpcNetwork -PrivateDnsRegistrationType WithConnectionDnsSuffix

One thing to beware of - check out the warning at the top of the hosts file. If you set  Managefile = False and manually alter entries previously managed by HPC Server things may get a little broken.

Digging through the versions

One thing I enjoy about Windows HPC server (and previously CCS) is a good discussion on versions, naming and compatibility. It's a veritable cauldron of confusion!
Here's my quick naming and compatibility matrix for head nodes / compute nodes, hope it helps more than hinders :)

OS version along the top, HPC Pack version down the left.

	Windows Server 2003 x64 Std / Ent Edition (+SP2; +R2)	Windows Server 2003 x64 HPC Edition (+SP2; +R2)	Windows Server 2008 Std / Ent Edition x64 (+SP2)	Windows Server 2008 HPC Edition x64 (+SP2)	Windows Server 2008 R2 Std / Ent Edition	Windows Server 2008 R2 HPC Edition BETA
2003 Compute Cluster Pack (+SP1)	Head node Compute nodes	Headnode Compute nodes	Not Supported	Not Supported	Not Supported	Not Supported
2008 HPC Pack (+SP1)	Not Supported	Not Supported	Head node Compute nodes	Head node Compute nodes	Not Supported	Not Supported
2008 HPC Pack R2 BETA	Not Supported	Not Supported	Compute nodes only	Compute nodes only	Head node Compute nodes	Head node Compute nodes

There's more of this type of thing surrounding SDK and Client component versions, I'll post about that later...

Windows HPC Server 2008 R2 Beta 2

It's been out for a short while, but the HPC team blog has just announced availability of Windows HPC Server 2008 R2 Beta 2. I've been running it on a test rig and first impressions are extremely favourable. I'm particularly liking the additional diagnostic features, and inclusion of a node image capture will save a bit of manual  imagex stress. Some of the new scheduling features (particularly enhanced activation filter) are looking really nice too!
One other thumbs up for R2 is the ability to use a remote SQL Server instance. There are quite a few technical and management reasons why this is a great addition, and the financial benefit when running HA headnodes in an environment where a SQL cluster is already in place is an obvious plus point.

Try to get to SuperComputing.

I was fortunate enough to attend the SuperComputing conference in Portland, OR last year, and can honestly say it was a blast. I've been to several similar large events in my time, and SC09 was right up there amongst the best. I'm not sure if it was the location (I loved Portland, what an awesome city!), the people (hung out with some fun individuals), or the conference itself, but it was fantastic all round.
I'll be hoping to get out to New Orleans for SC10, maybe I'll see you there...

Do you really need it?

The world of HPC is studded with cutting edge technology, all of it at a price. The question is do you need it?
This sounds like a simple issue, but in reality it's often quite a challenge to determine whether something will provide increased performance for your (or your users) jobs.
To cut a long story short, the most useful thing you can do to come up with the answer is to determine the requirements of your problem space. Are your tasks particularly reliant on disk IO? Do you have a sensitivity to latency? Maybe your cluster is used to run lots of single processor jobs and does not require high MPI performance at all. Once you know this it's easier to cut through the admittedly shiny technology and focus on what would be of most benefit to your environment.

Damn there are some clever people out there

The technical computing world is populated with some scarily intelligent people, seemingly brought up from an early age on complex algorithms and deep mathematical theory. Unfortunately I am not, and will never be, one of these people no matter how hard I try, so I have to look for other ways to make myself useful.
Luckily, skills developed in the enterprise world are also useful when managing Windows HPC Server, as a lot of the building blocks are common. Aside from a technical tool belt armed with AD, SQL Server, WDS, DNS etc etc, some of the softer skills can be very useful too. Knowledge and experience of support processes, project management, incident resolution, dealing with customers, and service delivery are all as applicable in the HPC world as any other environment.
After all, your carefully constructed and configured cluster is providing a service to your customers which is often as critical as any enterprise offering.

Receive-Side Scaling & MPI

I recently spent an interesting few days discovering, diagnosing & resolving an MPI performance issue on a small Gigabit Ethernet interconnect based cluster. The problem first came to light after running the MPI quick check and Throughput diagnostics from within the HPC Cluster Manager diagnostics suite. Results were significantly down on expected values, returning an average of just over 200 microseconds latency and just over 60MB/s throughput. Expected figures are closer to 50 micoseconds and 105MB/s, so something was quite obviously amiss.
After checking that all appropriate firmware and drivers were up to date the issue was still apparent. Time for some good old fashioned detective work, driving the problem in to an ever smaller box until the answer popped out. Following many combinations of driver version and network setting configuration, the culprit turned out to be the Receive-Side Scaling feature when enabled on newer versions of the driver in question. When turned on and configured to use <1 queue performance was degraded. When turned off, or turned on but configured to use a single queue, performance was as expected. Interestingly when using older versions of the driver RSS could be on and configured to use multiple queues without any performance degradation.

During the investigation I spoke to Xavier Pillons, a Windows Server performance guru at Microsoft, and he came up with some very useful tips which I'm sure he won't mind me sharing:

1.Check the driver release version.
2. Check the TCP Global parameters (use the command line Netsh int tcp show global).
3. On Windows server 2008 try to disable RSS, and play with Chimney Off/On.
4. For a better latency you can disable Interrupt Moderation Rate on the Network Interface.

Problem solved, or at least a workaround found. Happy Days! :)

High Performance is Relative

Whenever you read big announcements and stories about HPC in the press, they tend to concentrate on mega clusters dedicated to solving some of the giant problems of our times. It may be climate modelling, genome research, finding cures for terrible diseases, or unlocking the secrets of the universe. All very worthy causes I'm sure, but chances are your problems are slightly smaller scale, yet still require heroic solutions. Maybe you need to design your new product in half the time, or you need to make your current product 50% more efficient. You might be looking to calculate insurance premium returns, or recover from the global downturn in as short a time as possible.
Whatever you hope to achieve from HPC, the results can be heroic on a personal level, even if it just means you get a well done from the boss!

Diagnostics in HPC Server 2008 R2

A very interesting  post on the Windows HPC Team blog regarding diagnostics in HPC Server V3. I'm really looking forward to third party custom diagnostic tests, should be a very powerful feature indeed. Much of our work is based on management and control of individual jobs and groups of linked jobs, so I'm sure we'll be looking to create appropriate custom tests based on this framework.
I can certainly imagine a scenario where a Systems Center Operations Manager management pack kicks off in house custom tests, then alerts warnings and errors back to operations staff via the SCOM console where appropriate.

The Hit Parade

So, I've been thinking about some stuff about my time as a Windows HPC Sysadmin which I'd like to share, & the more I think, the more top level bullet points I come up with. I thought I'd kick off this blog with a couple of top tens. The first are somewhat abstract topics, the second specific to Windows HPC Server. I'll then follow it up with some more detailed blog posts which dive a little deeper into each of them.

So, without further ado, I give to you:
The Ballpark, and The Strike Zone

The Ballpark

Increase your generic High Performance Computing smarts.
Many new Windows HPC Sysadmins will be heading in from the Enterprise, having expertise in Microsoft platforms but relatively little knowledge of HPC.

Trust the product group.
You know, no-one's perfect, but the HPC product group come pretty close.

High Performance is relative.
You don't necessarily need a multi-thousand core set up to produce heroic results.

You get out what you put in.
Contributing to the Windows HPC forum has been a very useful process.

Damn there are some clever people out there.
Sometimes I just feel inadequate, desperately trying to wrap my feeble brain around complex problems discussed by some of my peers.

Do you really need it?
There's a bunch of people out there intent on selling you a bunch of kit, but is it right for you?

The methodical process of troubleshooting.
My advice - start from the bottom & work up... or start at the top and work down.

Don't forget the basics.
There's pleasure to be found in the simple things in life. Or, if you want to be blunt, keep it simple, stupid!

The business is (nearly) always right.
I find there's direct correlation between good business reporting and being left alone to get on with work.

Try to get to SuperComputing.
No, really, it's a great show, with great people.


The Strike Zone

Know your underlying infrastructure.
You only need to look at the Top 500 results to know that alot of HPC kit does not currently run Windows HPC Server. This means that many Windows HPC Sysadmins will be transferring their expertise from Linux (or other OS) based systems.

It's all in the name
How does Windows HPC handle name resolution?

Digging through the versions
SP1? Well, yes, but SP1 of what? And R2? Is that beta or RTM? So you want to install what on where now?

Performance enhancing shrugs
Well, it seems to run OK, but is OK good enough?

The database interloper
SQL Server? In every Windows HPC Server deployment? Surely not.

PowerShell is powerful
OK it might sound like an obvious statement, but it's true! At the risk of offending those not listed I have some favourite HPC PowerShell Commandlets I'd like to share.

Network topology - choices choices
RRAS, dedicated router, managed firewall and the like.

Monitor Lizard, the thinking person's test rig
If you've ever tried to compile HPL to run on Windows HPC you'll absolutely love Lizard. Performance results aside, it's a great starting point for cluster verification.

Node deployment
If one person with one DVD takes 2 hours to build one compute node, how long would it take that person to build a tree house?

A job a day keeps the user at bay
Become one with your users, know what they know, type what they type.