Colocating Servers and Managing them Remotely
The deal has been inked, your client is going to colocate servers at a datacenter featuring a fat 100Mbps pipe, and you're the guy who is going to make it happen. Luckily, there are only ten thousand questions you need answered. One of them probably is how you'd control all of these machines remotely if they became inaccessible via the network for some reason. Come on; if you're anything like me, you too have found yourself locked out of your system because of a boneheaded misplaced firewall rule.
See, I don't plan on visiting that datacenter very often, and the idea of instructing their staff to fix my machines (at $125/half hour) is unappealing to say the least. The more we can control remotely, the better off we'll be.
Without getting fancy, we evaluated two options:
KVM-over-IP: KVM switches are those things you're destined to see in heavy-duty Windows environments. Typically, they allow you to connect many computers to only one set of keyboard, mouse and monitor, and they provide some kind of switch to flip between computers. KVM-over-IP would be one of these KVM switches with a network or dialup interface.
Terminal Server: An appliance that we can connect to our servers via a serial link to access each system's serial console. Once connected to the terminal server (via network, dial-up modem or other), you simply choose which server's serial console you'd like to access.
We decided to go with a terminal server, the Cyclades-TS1000 16-port model to be precise. Without going into an arduous KVM-over-IP vs. Terminal Server debate, here are the key factors that helped decide it:
The Cyclades-TS1000 runs an embedded Linux system. You can log into it and run close to anything you want with enough poking. From reading the manual alone, it is clear that the TS1000 has a variety of uses and that our setup is perhaps one of the most trivial ways it can be deployed.
You can either Telnet or ssh into the TS1000, but practically speaking you can probably get it to speak or authenticate against anything. Major brownie points here.
Cyclades Corporation clearly gets it. In one issue of Don Marti's Aspire To Crudeness, he notes: ``Cyclades, for you Linux history buffs, was the first company to support development of Linux drivers for its hardware (a multiport serial card). They gave a card to the driver author.''
I don't know about you, but whenever I have to deal with KVMs, I find that they're quite sub-par. For reasons that no one can explain to me, a display can lock up on you, and there is no way to alleviate the problem besides rebooting the server with the afflicted display. This isn't limited to one manufacturer; I've seen this on every KVM that I've ever used. Thoughts of frozen KVM displays during an emergency danced through my mind. Perhaps other people are used to rebooting their machines to fix mysterious computing problems, but I'm sure not.
The terminal server was cheaper than the KVM-over-IP, by about $1200 when we last checked.
Bottom line? The Cyclades won, or as Don Marti noted to me, "You don't see people managing Beowulf clusters with KVMs."
We ordered our 16-port Cyclades Terminal Server plus 16 DB9-RJ45 cables that hook into each system's COM port (the Cyclades ports are RJ45). They also threw in some extra cables just in case, including a special Sun Netra cross-over cable. Very thoughtful.
Configuration of the Cyclades TS-1000 is performed using a plain vanilla serial cable and a terminal emulator. I used minicom and configured it to open /dev/ttyS0. Since the Cyclades appliances are so powerful, they require a bit of end-user configuration. Luckily the printed manual that accompanied our Cyclades held my hand through the entire process. If you can configure sendmail, Samba or Apache, this should be no sweat. Once the initial setup is complete, the Cyclades can be accessed via Ethernet, dial-up or anything else you think of.
To be honest, I was actually expecting to have to log into the Cyclades and run some terminal emulator against a serial device (such as /dev/ttyS4 to access link 5). Those clever devils at Cyclades went one better; the TS-1000 creates a virtual network interface for each serial link, complete with its own IP address. With glee, I made up an internal subnet (10.0.1. to be exact) for the serial links.
From here, you can simply Telnet to each link's corresponding IP address from your Cyclades session, and you should have a live serial link to your server. If the idea of logging into the Cyclades to then Telnet to an IP address seems arduous to you, you can route the addresses onto the LAN so you can skip the Cyclades login. However, if there is a risk that strangers can make this connection, the Cyclades should be configured to authenticate clients before giving them access to the serial link.
Standard Net safety rules apply here as well. If the Cyclades is going to be accessed over an insecure network, ssh should be used instead of Telnet. In addition to protecting your communications with anti-mean-people-cryptography, ssh can be configured to allow for passwordless logins and other convenience features. In fact, since ssh provides the same features as Telnet without the insecurity, you may want to simply disable Telnet on the Cyclades altogether. Simply comment out the Telnet line in /etc/inetd.conf and send signal HUP to the inetd process.
- Cross-Platform Software Development Using CMake
- Asynchronous Database Access with Qt 4.x
- Let's Automate Let's Encrypt
- Non-Linux FOSS: Scripts in Your Menu Bar!
- That First Gulp of Java
- Dynamic Kernels: Modularized Device Drivers
- Building a Distributed Spreadsheet in Modula-3
- Why Python?
- Meet OpenVPN
- Virtualization in Xen 3.0