A Guide to Virtual Services
As Internet sites grow in number, some clients want to create a presence without dedicating a machine to the task. In many cases, a client may never get the amount of usage which would justify a dedicated machine. People like florists and civic event organizers may not have any other use for the machine, so the extra hardware would go to waste.
The solution to this problem is to use a single computer to serve multiple clients. If the machine is serving web presences, FTP directories, and e-mail services almost exclusively, a single machine with enough horsepower can easily handle the needs of several clients, especially those with low traffic.
However, this solution has a drawback, with which many are familiar. Although several domains can be easily pointed to a single host, the URLs will produce the same results regardless of which service, and which domain, was requested. For example, if tryme.com and comehere.com both pointed to the same host, http://www.tryme.com/ and http://www.comehere.com/ would produce exactly the same main page—clearly not what these organizations would have in mind.
But this problem has a solution—virtual services. A virtual service is exactly like a standard service (Web, e-mail, or FTP), but it provides different results depending on which target was selected, despite the fact that they all reside on the same machine.
This month, we examine how to set up and use a virtual web service. Next month we cover e-mail and FTP, as well as possible future capabilities. Keep in mind the Perl motto: “There Is More Than One Way To Do It.” As the Internet has grown, several alternatives have sprung up. This document describes only one method, and by the time you read it, there may be others, so look around before you decide on any one path!
Please note, in all the solutions described, I assume that you have at least two domain names registered and operating, and two IP addresses. You should have working routes to both IP addresses, and nslookup from any outside Internet host should return the correct IP address for each domain name. You can consult other references for information on how to do this.
IP aliasing is the key to the virtual services on the level of the operating system. As the intended audience of this article is Linux users and system administrators, I will present only the information pertinent to Linux. Other operating systems may or may not have the capability to do IP aliasing, and you should consult your documentation and other publications for information on them.
Under normal circumstances, only one IP address may be tied to each network device. The virtual services described in this article rely on having a separate IP address for each domain serviced. How, then, does one manage all the traffic with a single machine? IP aliasing makes this possible.
To enable IP aliasing you must first compile your kernel with IP aliasing support. If you don't already have the kernel sources, you shouldn't continue without them. Obtain a fairly recent kernel distribution from a suitable mirror site and unpack the archive, typically into /usr/src/linux. Then go into the directory and re-make the kernel. Be sure to answer “Yes” to the question about whether or not to support IP aliasing.
If you think your kernel might already support IP aliasing, a quick way to check is to verify the existence of /proc/net/alias* files. Once you have the support enabled, you simply need to configure the interfaces in a slightly different manner. Normally this would be done with a combination of ifconfig and route. The following is a common example:
/sbin/ifconfig eth0 10.1.1.10 <other options> /sbin/route add -net 10.1.1.0 gw 10.1.1.10 <other options>
This creates a setup for the eth0 device (which you should replace with whatever device you use for your connectivity) and adds a route for the local network (10.1.1.*) to go through it. (This will also automatically handle the route to the device itself.)
To handle IP aliasing, we simply add a colon and the alias number to which we want to refer. If we had obtained IP addresses 10.1.1.6 and 10.54.21.8 from our service provider, and we wanted them both to talk to our ethernet card connected to our T1 router, we would use:
/sbin/ifconfig eth0:0 10.1.1.6 <other options> /sbin/ifconfig eth0:1 10.41.21.8 <other options> /sbin/route add -net 10.0.0.0 dev eth0:0 /sbin/route add -host 10.41.21.8 dev eth0:1
This will set up two aliases for the Ethernet card, 0 and 1, each with a different IP address. All traffic to either IP address will be seen by any daemon listening to the Ethernet device, and traffic anywhere in the 10.* realm will be routed out through the first device, as a safety catch. You may need to modify these lines to support additional options and, perhaps, a default route. That is all there is to it!
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Validate an E-Mail Address with PHP, the Right Way
- Weechat, Irssi's Little Brother
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Poul-Henning Kamp: welcome to
1 hour 12 min ago
- This has already been done
1 hour 13 min ago
- Reply to comment | Linux Journal
1 hour 59 min ago
- Welcome to 1998
2 hours 47 min ago
- notifier shortcomings
3 hours 11 min ago
4 hours 48 min ago
- Android User
4 hours 49 min ago
- Reply to comment | Linux Journal
6 hours 42 min ago
9 hours 32 min ago
- This is a good post. This
14 hours 45 min ago
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?