I’m going to LISA!

I wasn’t certain that I would be able to attend until today when I got my registration sorted out. I’m going to be attending LISA ’09 in Baltimore, MD. I’ll be there from Saturday, November 1st through Friday, November 6th.

This is going to be my first LISA, and it’s going to be quite an experience. I’ve been chosen as one of the official conference bloggers, which means that I have to be in a ton of places and write about everything. It’s going to be a blast. Last year’s blog is still online. The solitary blogger, Matt Sacks, is doing the coordination this year, which will probably be a job with complexity somewhere between herding cats and air traffic control. I don’t envy him.

Saying that something at LISA is of special interest is like saying “there’s one particular piece of architecture in the Pantheon…”, but anyway, since I pretty much live, eat, and sleep the idea of small infrastructures, I’m all over the microLISA workshop, which is dedicated to small infrastructures.

Also, in the evening, there are Birds of a Feather sessions, which bring together like-minded people to informally discuss topics. I’m organizing two of them, both on Thursday. From 9:30pm until 10:30pm, there will be a “Small Infrastructure” BoF, since the conference technically starts on Wednesday and lots of people will have missed microLISA. Immediately following it is the “Bloggers” BoF, for LISA attendees who are either currently bloggers or who want to be. I’m sure there will be more sysadmin bloggers there, and it’ll be nice to put faces with names.

Between the training, the workshops, and everything else, I just won’t know what to do with myself. Drop a comment below if you’re going to be able to attend. I’ll be the sleep deprived geek typing a lot. I’m sure that’ll narrow it down ;-)

VM Live Migration is the wrong tactic

I’m sorry. I know you probably paid a lot for that license, but if your infrastructure is relying on a machine’s ability to transition between VM hosts without rebooting as the crux of your high availability plan, you might want to reconsider.

Yesterday, Rational Survivability (a great all-over-the-place IT blog) had a post titled The Emotion of VMotion. It didn’t occur to me before reading this that my own previous search for a hypervisor that would do live migration was working directly against my own beliefs that uptime should only matter for services. Essentially, the infrastructure should be designed so that a single server down doesn’t contribute to the loss of availability.

That being said, live migration is a neat idea, and eventually it’s going to get to the point that it’s nearly instantaneous. When that happens, failovers will be next to invisible. Maybe we’ll have to reevaluate our approach in that case.

Until then, I read posts from people trying to rely on it to keep their infrastructures up and I worry that their approach is flawed.

Please, build your services for reliability, not just the underlying systems.

How much are those upgrades?

Sometimes the most painful exercises are the most valuable.

I spent an hour or so yesterday in a meeting, going over every line of expense in my new phone upgrade plan. It was grueling. It was also enlightening. Know what I found out? I need to pay more attention to the “small stuff”.

If you’re at all like me, when you plan upgrades, you probably have a mental picture of what’s involved. You say “I know X needs upgraded, and when we change X, Y is going to need to change, too”. So you calculate the requirements for changing Y, add them to the requirements for X, and sum the results. Of course, lots of time, changing Y requires alterations to Z. When does it stop?

When it’s done.

Sad but true. I had mentally done the requirement scavenger hunt, but my problem was that I stopped too early. I didn’t investigate all of the possible leads, and I didn’t chase it down to the finish. What did that nearly cost me? A few weeks and a few thousand dollars. It turns out that upgrading VoIP phones doesn’t just require upgrading bandwidth. Or upgrading the phone system. Or buying phones. Or buying PoE switches. Which is sad, because that’s sort of the end of the line for my train of thought. I thought I was being thorough. But no. As it turns out, those PoE switches have to connect to the VoIP phones somehow. Using cables typically, so I hear.

As it turns out, we currently have ethernet lines for computers in that office. Not phones and computers, just computers. There are phones that contain a “hub” port on the back, that you can use to connect to the computer, so that you only need one port, but the wiring in that office is in a state of disrepair beyond the scope of this entry. It deserves it’s own entry, which will come at some point in the future.

In any event, new cable runs are needed, and sadly, they don’t grow on trees. Honestly, I can’t believe I neglected this until now. And I wouldn’t even have thought about it now, unless someone prompted me with the line “I don’t care how small the expenditure is, I want to know about it. I don’t care if you have to order cables for the phones, I want the price included”. Oops.

But this is how we learn, and making mistakes is a part of that process. Don’t hide your mistakes, or lie to yourself that they didn’t happen. You can’t improve that way. Accept them, find the reason you made that mistake, and fix it.