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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Designing Electronics with Linux
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
2 hours 50 min ago
- BASH script to log IPs on public web server
7 hours 17 min ago
10 hours 53 min ago
- Reply to comment | Linux Journal
11 hours 25 min ago
- All the articles you talked
13 hours 49 min ago
- All the articles you talked
13 hours 52 min ago
- All the articles you talked
13 hours 53 min ago
18 hours 18 min ago
- Keeping track of IP address
20 hours 9 min ago
- Roll your own dynamic dns
1 day 1 hour ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?