Showing posts with label USENIX. Show all posts
Showing posts with label USENIX. Show all posts

20101113

New info about OpenGear from the USENIX LISA '10 conference

I'm just back from the USENIX LISA '10 conference (San Jose, CA). OpenGear was there (for their third year), but they were the only Console Server vendor in the hall. As a result, they got a significant amount of mindshare from the attendees. I spent a good deal of time asking questions, and I'm happy to say that they had sent some technically-deep folks to staff the booth. (They also have a lot of Conserver experience, which qualifies for extra points in my book. ;-)  I wish more vendors would have come to the LISA conference. With a great international draw, the LISA attendees have significant technical depth and come from some very large corporations. It would seem to be a fertile ground to collect contact info, and provide information to be carried back to universities and big corporations. We'll see you next year in Boston, right?

It's another example of Moore's Law... even in the last year, there are fewer Console Server vendors (Emerson acquired Avocent (who had acquired Cyclades...)), and OpenGear has made many significant improvements in their hardware and software. But, more important to me, is that OpenGear has continued to be attentive and responsive to their customers, not only for me!

What's in it for you, as a Console Server user/customer? Plenty! Customer needs have driven them to provide some really interesting new hardware this year, and they have also given customers the option to use the OpenGear RJ-45 wiring scheme, or order hardware matching the Cisco/Lantronix/Sun symmetrical RJ-45 scheme. Thanks to Jared Mallett and Todd Rychecky for sharing good info with booth visitors, here's some of what I heard;

    They have upgraded the CPU and storage in their smaller devices!
    They have a 4-port model, running on DC power...
    Some smaller units have 2 network connections (dual Ethernet, or Eth and G3 cell modem!)
    They have also made provisions for external FLASH for logging, etc.
    Security improvements include Single Sign-On, and FIPS 140-2 Crypto module
    Participating in the RSA Secured Partner Program SecurID integration

Two weeks ago, I learned of a project that wanted a 4-port device... last week, OpenGear showed me their Dual Ethernet 4-port device, shipping by default with Cisco RJ-45 wiring. Problem solved!

As we approach the holiday season, the daylight gets shorter, and (with the holidays, and folks taking extra time off) the calendar itself seems to get shorter, and deadlines start to loom large. If you need console servers, take a look at OpenGear, and see if you can find what you need quickly.

       Happy holidays!     -Zonker-

20080713

Social Networking, professional connections

The question comes up, from time to time... Why do System Administrators seem to be better at (Social) Networking than Network Administrators. You'd think that Netadmins would have the communications thing down cold. But, I've found, we tend to have smaller social networks, but with links we can rely upon to do our jobs.

Linked in? Yep, I've been there a while... View David K. Z. Harris's profile on LinkedIn

But, why are there so many more Systems-related conferences than Network-related? OS related trade shows, versus Network trade shows.

I just find it odd, that's all.

-Z-

20071230

Happy New Year! It's about time...

Time for a New Years Resolution! Establish an NTP server at every site I work on, and point as many devices to it as I can. (I'll do this to save everyone some time.)

Consider taking a look around your installation. How long would it take to check the uptimes of the devices, and also check their on-board Real Time Clocks. How many do you think are correctly showing the current time, within +/- 10 minutes? For your network gear, how many are showing log timestamps as the "from startup" uptime stamp, instead of a date/time notation?

Now, consider that, in the time it would take to EVALUATE your clocks and timestamp settings, that you could probably FIX THEM, not just record the results! If you plan to go and touch all the gear anyway, why not save some time, and SET the clocks, instead of checking them?

But, when was the last time anyone bothered to do this, in your installation? Maybe the clocks on your devices only get set when each device is installed. (If you ship devices between data centers, across timezones, do you make a point of changing the device clocks when you receive them into your installation?) Let's face it, these clocks are cheap, and they ALL have some drift in them. Even if the drift is minimal, the error is cumulative, and can be significant across 3 or more years. You complicate the drift when you don't use a stable starting point. (What time reference does everyone use when they set device clocks? Probably their independent wrist watch?)

In the same way that you need to spend some money to make more money, you need to spend time to make more time! NTP is a great way to set clocks, and keep them close to the current time. (Even a daily time sync will all but eliminate the effect of drift on the cheap clocks.) Most devices have a no-cost client available, and many servers and some network gear have a no-cost NTP Server option available. If you have a complicated network, with multiple customers or DMZs, you can invest in an appliance that uses GPS or the cellular phne service to provide a drop-in connection on an isolated network. You just need to take some time to set up a server, and then set your devices to be clients.

Technically, all of this work (and invested time setting up NTP) doesn't save time, per se. What it will do is reduce the time you spend tracking down problems. Calculating time-math is hard. Correlating time offsets in log files between devices with unsynchronized clocks takes a LOT of time. But, when you have an "event" in your installation, and you need to find the Root Cause, you need to compare a bunch of logs, to figure out what happend first, then second, and etc.

If you take the time to set up an NTP server, you make it quick and easy to 'set and forget' the clocks on new devices coming into your installation. When you take the time to point all of your existing devices to the NTP server, you'll save time comparing the logs on all future 'events'. It's hard to guess how much time, or how soon you will recover that time, but it WILL happen. Just give it time.

-Zonker-

Some NTP appliance resources I've found to be interesting:
VMware NTP appliance VM info
Symmetricom S200
J-Time (Meinberg USA) Lantime M300
Brandywine Communications NTV-100RG