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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide