Serial Port Concentrators vs. KVMs
Gerry Creager N5JXS
gerry.creager at tamu.edu
Wed Apr 23 19:00:39 EDT 2003
ALthough in a different context, we use both. And an additional approach.
We use KVM switches in my virtual network engineering lab environment
when we're working in the lab and doing "console" access locally:
Resetting/rebuilding systems, adding hardware and fine-tuning, etc.
We use Concentrators for our remote access, although our application is
a little different from most: Our Cyclades systems are isolated in a
private network, and we have front-end systems to access them. This
system has worked very well for our lab exercises. We can keep the
number of connections and logins relatively low, which is one place the
terminal concentrators fall down on: too long to log in, IMHO.
We also use the generic equivalent of a Head node, which we refer to as
a 'Bastion" box. This allows ssh access to the sandbox area for
terminal-type connections. The Bastion Host is accessible on ssh through
our campus firewall. We use a series of restrictive rules, especially
during our security classes (which are real, hacking, attack-defend
classes) to prevent students from accessing a system not their own from
the Bastion Host, and the Rules of the Game preclude use of the Bastion
Host from attacking.
In summary, we like all three approaches. There are times where the
Bastion approach is best and we try to utilize it there.
We like the Belkin 16 port KVMs when we've got to be in the room. We
don't like the 8- or 4-ports as they are not cost effective.
We like the serial concentrators when doing "serial console" tasks. If
you reboot a system, the Bastion Host won't maintain the connection
during the process, while the serial system will.
Series of tradeoffs and we've tried to ascertain what works best for us...
Gary Stiehr wrote:
> Having used both KVMs and serial port concentrators, I have my own
> opinions about the advantages and disadvantes of each. I was hoping
> that list members might share their opinions as well. My experience is
> with Belkin 8-port KVMs and with a Computone RAS2000 serial port
> concentrator. Here are some of my opinions, please feel free to add to
> the list or correct me if I'm wrong. In particular, any comments on
> scalability or some price comparisons would be interesting.
> KVM Advantages
> * Ease of Setup: usually you just run the keyboard/video/mouse cables to
> the KVM and then a set of keyboard/video/mouse cables from the KVM to
> some other node from which you can access the console for all of the
> nodes attached to the KVM. There usually is nothing that needs to be
> done with the OS (although I've heard of some BIOSes having problems but
> I've never experienced this). There is also usually nothing to set up
> with the KVM itself--just hook up the cables.
> KVM Disadvantages
> * Lots of cables: Even if you do not use a mouse cable, you still have
> two cables running from the back of each node. I have heard of some
> KVMs lately that use an adapter to combine all three kvm cables into
> one. I have not actually seen or used one but that would certainly help.
> * No remote access: The only KVM switches that I have seen with remote
> access are "enterprise" KVM switches that have a high price tag. I have
> no experience with this type of KVM switch but I would imagine it would
> be like a hybrid KVM/serial port concentrator.
> Serial Port Concentrator (SPC) Advantages
> * Remote access: Most SPCs that I looked at listed remote access as a
> feature. And some, including the Computone RAS2000 that I use, allow
> you to access the them via ssh.
> * Less cables: You only need to run one cable from the back of each node
> (from the serial port) to the SPC.
> * Multiple access methods: As noted above, you can access a lot of SPCs
> via the network. But if that is down, you can also access the SPC via a
> node that is attached via serial port to a special port on the SPC.
> Serial Port Concentrator (SPC) Disadvantages
> * Need to set up the SPC itself: In my case, this wasn't too bad.
> Unfortunately, I would think that each vendor would have its own set of
> procedures to follow for the setup of its own SPC.
> * Somewhat of a learning curve: If you have not had experience with
> serial ports (i.e., you know what they are but you've never done
> anything with them), there will be a lot of terms that are unfamiliar.
> You will also need to find out a lot of information about your hardware,
> OS and BIOS. For instance, what speed do they support (9600 baud,
> 115200 baud, etc.)? What terminal emulation do they support (vt100,
> vt102, ansi)? Is my serial port enabled in the BIOS? Which serial port
> is which (For Linux: /dev/ttyS0, /dev/ttyS1, etc.)? And so on.
> * A significant number of small changes to OS: There are a number of
> changes that you need to make to the OS (in my case Linux) in order for
> the console messages to be sent to the serial port. Thanks to various
> how-tos and other docs, I was able to make all of the appropriate
> changes but a lot of them were not very obvious (although once you read
> about them you can see why it would be necessary).
> * Must access the BIOS on each system: Unless your BIOS has serial port
> redirection enabled by default (if it has this feature at all), you will
> need to access each BIOS as you set the systems up (if you want to see
> console messages generated by the BIOS).
> Thanks for reading this somewhat lengthy e-mail. I would appreciate
> your comments.
> Thank you,
> Gary Stiehr
> gary at umsl.edu
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf