Alright! Lets get this started again.  There is one last thing we need to do in order to have networking on the cluster functional.  Right now, the nodes inside the cluster can’t speak to the outside world.  While we set up the head node to be able to speak to things on every interface, we haven’t yet told it how to move traffic from one interface to another.

Making the Gateway

In normal clusters, there are three types of notes - workers, gateways and head nodes.  Workers do whatever task the cluster is intended for.  Head noes manage the workers.  And finally, gateways, which allow the worker nodes to communicate with things outside the cluster.

Gateways are needed because clusters often use IP addresses which are not publicly routeable.  The gateway allows the entire cluster to sit behind one IP address and is in charge of routing traffic properly.  This process is called Network Address Translation.  In many ways, this makes the gateway like your home router.

Anyway, …

Hey world!  I’ve been inactive here the last month and a half because my semester got intense and I, frankly, didn’t have time.  In this time, I’ve kept working on all my projects, job hunted and got hired.  Phew.  Busy time.

In any case, this is a “hello! still alive!” and a warning that you’re probably going to see me post quite a bit here over the next few days as I catch up on my backlog of documenting things.

I gave a talk to JHUACM this evening about version control.  Pretty basic stuff.  Anyway, I thought I’d put a clearer link to my slides online in case it was useful for anyone.

Slides, PDF foramt

Slides, ODP format

Hey everyone!  It’s been a bit of a lazy weekend - I’ve mostly been doing schoolwork.  I had some success with JHUACM cluster stuff that I haven’t written up yet (its fun!  I rewrote the spec file for building RPMs of a proprietary driver!).  However, I’ve come across a cool video to share.

Time Lapse: Endeavor’s Trip Through LA

In case you missed it, the space shuttle Endeavor recently moved off to it’s new home in the California Science Center.  The LA Times’ Brian Chan put together a time-lapse video of the move.  For your convenience, its embedded below:

What struck me most about this video is the meticulous amount of planning that must have gone into this move.  Everything from the devices the shuttle is resting on to having precisely measured the streets and the trees and making sure that there would be space.  Throughout this time lapse the shuttle’s movements look choreographed, perfectly planned for this route.  They even managed …

(This post is related to the ACM cluster build.  However, it is really generic systems stuff and not terribly related to the actual cluster build.  It is much more closely related to quirks of JHU networking.)

The Problem

JHU has two distinct networks - firewalled and firewall-free.  (In truth there are more and there are gradations, but these are the two JHUACM has IP allocations on.)  Some services cannot be run form inside the firewalled network.  For these the ACM has a small firewall-free allocation.  Because the cluster will be hosting VMs inside both networks, it needs to be capable of routing traffic from both.  This means doing something called source-based routing or multihomed routing.  This refers to the fact that this machine will have two connections to the internet.  Typically, this is a very rare setup - Multihoming is usually used at the ISP or datacenter level, rather than at the level of the individual box.

The Solution

The solution is to convert linux to …

So I’ve mentioned that I’ve been fighting networking again in the ACM cluster.  I’ve been reworking the network.  This whole adventure began after a conversation with the very knowledgeable nwf, who pointed out that JHU runs two different networks that the ACM systems need access to - CSNet (the JHU Computer Science department’s network) and JHU firewall-free (which has unfiltered access to the internet).  The goal of this rework was to allow the cluster to be on both.  In a situation with more resources, I would have simply bought another network card for each of the gateway nodes.  However, I don’t have those resources and couldn’t find any spare network cards.  nwf then pointed out that I would be able to use 802.1Q vlans to make more virtual ports.

So, here’s how this works:  CSNet and JHU firewall-free (JHUFF) each plug into a single port on the main switches.  These ports are assigned as being on specific vlans that differ from the other …

So.  I’ve been quiet lately.  I’m still working on everything I was before.  But, the semester is in full swing, so I’ve had exams to study for.  This weekend, however, is going to be mostly ACM stuff.  A lot of that will be cleaning (I’ve made a mess with all the cluster gear lying about), but if I’m lucky, I’ll have a post early next week about the new network configuration for the ACM.  Especially if I can figure out how to get the switches to send well-formed DHCP requests over non-default vlans.  I might also have a writeup of getting the storage stuff built and of kickstarting nodes.  We’ll see.  I’m working on the cluster on many fronts.  And sometimes one distracts me from the others.

Not much to say today - I’m busy working on a project for class (Its fun!  Timers and sockets and protocols! (Oh my!)).  However, a friend of mine posted a link on G+ I thought was really cool and wanted to share.

So without further ado: Throwing one’s voice 95 miles on a lightbeam - from KA7OEI.

As a techie and ham myself, I think this is really cool.  It gets you into all sorts of things you don’t usually have to think about - earth’s geometry, atmospheric attenuation of light, and data encodings, to name a few.  I don’t actually know anything about the technology involved, but I thought this would be worth sharing just for the wow factor.

Thanks to my very talented friend Kyle M., I now have a site design!  I rather like it, but please do let me know if you find things that don’t render properly or any other issues.

And many many thanks to Kyle for producing something better than anything I could ever hope to make.

As part of my ACM cluster creation obsession, I wanted to make the Cisco 2900XL switches we have autoconfigure.  I’m not terribly familiar with how these switches operate and, rather than reconfigure all of them at once, I’d much rather be able to reboot (reload, in cisco parlence) them and have them come up with my new, clean config.

Fortunately for me, Cisco thought of a situation like this when building the software for these switches.  According to this page from their instruction manual, if a switch boots and doesn’t have an in-flash configuration file, it will DHCP/BOOTP for a network address, then attempt to TFTP one of several files - network-confg, cisconet.cfg, router-confg or ciscortr.cfg.

In my case, I’m running this next to xCat, so I already have a TFTP and DHCP servers running.  Furthermore, my switch was already set up in xCat to get a static address.  So all I really needed to do was put in the configuration file.  But how to generate …