How do you approach your virtual networking?

I ask silly questions sometimes, but I do it for a reason. As a teacher, I i try to inspire you to think. So I ask questions that may seem a little goofy, but I also try to gently guide you down a new path.

I’ve been using this for a while in my vSphere classes (everything I teach that discusses networking, at least) and thought it was worth sharing. I lead off the discussion with a simple question: do you treat an ESXi host any differently than any other physical server while planning to attach it to the network? Sure, an ESXi host likely has more interfaces to cable, but that’s not all you need to think about. A fundamental shift in thought process should occur when thinking about your vSphere hosts and your network.

If you look at the vSphere network architecture long enough, it’s clear that you’re not just connecting a host to your network. You’re actually connecting more infrastructure to your network. You’re connecting physical switches to virtual switches, not connecting hosts to physical switches. Your vmnic devices aren’t really NICs at all – they’re bridging physical Ethernet to virtual Ethernet. Once that realization is made, everything’s different.

I’ll admit, I didn’t come to this realization all on my own – a friend of mine actually introduced me to the idea. We were discussing something about a class, and he drew on the whiteboard something that could easily be described as a cabinet in the context of a physical data center, and then began to explain that it could just as easily represent an ESX host (this was a couple of years ago). And the epiphany struck.

It’s easy for us systems guys (and gals) to avoid this thought process. We were never programmed that way. But the times, they are a changin’, and we need to remember to change with them.

If you think about your networking like any old host, let me suggest, kindly, that you’re doing it wrong. Start thinking about adding a cabinet to your raised floor, and then you’ll be right on track.

Is scripting an important skill?

So, yesterday, a colleague posed an interesting question. “Is scripting an important skill for a system administrator”?

I’d like to answer that question with a very resounding “YES!” Frankly, I have to question whether one is truly a system administrator without the skill to write a script (even if it’s simply a quick hack involving shell redirection). This is not about any particular scripting language. bash, ksh, Powershell, it doesn’t matter. Scripting is scripting. They’re all just different roads that lead to the same place: automation.

Perhaps my strong feeling about this come from my days as a Unix administrator (Solaris, primarily, but I have run Linux systems and dabbled in HP-UX). As an old-ish Unix jockey, my mentors always reinforced a common theme: if you have to do it more than once, script it! This mantra is not just because we can do more with less by way of a script, but is also for one’s sanity, really.

Let me share an example. A number of years ago, I was hired as a Unix admin for a rather large telecommunications organization. I joined their managed hosting group, and was expecting a reasonably boring life of MACs (Moves, Adds, Changes, for those unfamiliar with the acronym) – shuffling user accounts and data, adding users, groups, software, changing things on a request basis. But upon walking in the door on Day 1, they sat me down with the existing backup guy. 3 months later, this guy was no longer there, and it was just me running the backup system (we ran the backup infrastructure entirely on Solaris at that point). What’s worse, I was a rookie backup guy, and now I had 12 data centers to deal with, and I was running solo. Sure, I could have pointed and clicked my way through the X-Windows interface to the backup software, gotten RSI on my mousing arm, and gone absolutely mad knowing I wasn’t going to get any real help. But I’m all about working to live, rather than living to work. So I spent a little time learning the CLI underpinnings of my backup software, and everything that could be done (quite a bit more than via the GUI, mind you). Sure, my daily care and feeding fell behind for a little bit, but it was oh, so worth it in the end.

So I started building scripts. Reporting scripts, maintenance scripts, add a backup job scripts. If there was something that had to be done daily, I scripted something out. Weekly? Script. Monthly? Script. You get the idea. And then I loaded up my crontab in each datacenter, and I realized how much time I had to actually learn about backups and tape. All of a sudden, I had time to work with my counterparts in our engineering team to help shape the backup infrastructure. I could share pain points with them, and have data to back them up rather than anecdotes. We could dive into the real problems while I have nicely automated everything behind me. I also took the opportunity to start working much more closely with our FC SAN guys, which is a move that shaped my career for years after. Now, 6 months after I did all that work, I managed to start getting a team built up under me. Was the work all for naught? No way. Their lives were also made a bit easier as well. Were I better about my own personal data backups, I’d still have those scripts today 🙂

The moral of the story: Automation is a good thing. Not because we’re letting “the man” win and doing more with less. That’s just a side-effect. The real win for automation is that it frees us up from repetitive tasks so we can spend time doing more valuable things. And value is still what it’s all about. When your manager asks, in your annual review, “What value have you brought to the company this past year?”

Your answer could be “I worked long hard hours pointing and clicking my way through to make sure the bases got covered.” But wouldn’t you rather say “I automated the daily care and feeding of these 4 infrastructure applications my team owns, and have been working with {other team} to help them increase their efficiency by automating applications X, Y, and Z”?

I know which I’d choose.