4

I know this has been discussed in several places, but there doesn't seem to be a definitive answer yet - at least not for RHEL 6. I'm just hoping someone might be able to point to how it's working so I can dig a little.

Short Version: I have an OpenVZ Host Node with a public IP address which is acting as a reverse proxy to a bunch of OpenVZ containers with private IP addresses. I've created 2 containers with the same name (if you want to know why, skip to the long version below), and the HN also has these entries (amongst others) in its /etc/hosts:

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

I can use OpenVZ to suspend / resume either of these hosts by ID, and the reverse proxy seems to magically route requests on to whichever host is running (e.g. to either IP address 10.0.0.130 or 10.0.0.131. But I can't for the life of me find out which bit of software is doing this. Is it Apache? Is it something in the networking system of the HN? Something else? It seems to work, but I'd like to know more about why/how, as there also seem to be big differences of opinion as to whether it should work at all. To be clear, I'm not looking for round-robin or load balancing here. Just simple, manual switchover from one OpenVZ container to another.

Lomg Version: Whilst setting up some scripts to create and manage a series of OpenVZ containers, I created a script called make_clone.sh which takes a template and creates a new container. The script takes 2 parameters - the container ID and desired hostname. One of the things it does is allocate a new 10.0.0.* IP address for the container and configure some networking, of which one element is putting an entry into the Host Node's /etc/hosts file.

Whilst testing some backup/restore scripts for these containers, I wanted to 'pretend' a particular container had died, spin up another with the same name and restore the backup. Rather than actually delete the original container, I just used vzctl stop 130 to take it offline. I then created a new container with ID 131, but with the same name. Once it was up, I restored the MySQL database and checked (via a browser) that I could access it - it's running Joomla with some customisations - and all was well.

But then I noticed that in the Host Node's /etc/hosts, I had these 2 entries (amongst others):

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

The Host Node is also acting as a reverse proxy. Only the Host Node has an external IP address, and its Apache configuration effectively maps subdomains onto Containers. So, as well as the entries above in /etc/hosts, it also has sections like this in the httpd config:

` ServerName testbackup.xxx.yy

    ProxyRequests Off
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyPass /server-status !
    ProxyPass / http://testbackup.xxx.yy/
    ProxyPassReverse / http://testbackup.xxx.yy/

    <Location />
            Order allow,deny
            Allow from all
    </Location>

`

In the scenario I'm describing, it would actually end up with 2 of these sections due to the scripts, but they would be identical - it refers to the Container by hostname not IP, which makes me think it's not Apache per se that's picking the 'working' Container. I can now browse to http://testbackup.xxx.yy/ (using the real domain name, obviously) and Apache seems happy to route the requests on to whichever of 10.0.0.130 or 10.0.0.131 is up. I can switch between them by simply suspending / resuming the OpenVZ containers.

I wasn't expecting this to work - but it's nice that it does. My question is, should it? Can it be relied on? Or is it just a fluke that will stop working when whatever bit of fluff that's got into some other configuration file somewhere gets tidied up?

Community
  • 1
dsl101
  • 433
  • 1
  • 7
  • 13

1 Answers1

2

Since a host can have multiple IP addresses, what you're seeing is expected behavior. It's like having multiple nicknames, like: bossman, haus, jungle-jim, etc... Everyone who knows me, knows those are my nick names (they're not actually my nicknames, though).

Unless you're attempting to access the resource via IP address, your systems should work as if nothing happened. (Technically speaking, generating a new IP address on a container shouldn't affect your services, so long as those services aren't tied to the IP address. In your case, you might have just lucked out with your apps running over smoothly.)

Example: I could assign 4 IP address to one host:

10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
10.0.0.132 testbackup.xxx.yy
10.0.0.133 testbackup.xxx.yy

Example1

All of those IP addresses point to testbackup.xxx.yy, which means, if I attempt to access testbackup.xxx.yy, I will get to any one of them, depending on which IP address is active/responsive at the time of my request. Again, this only works, so long as the service you are attempting to access isn't tied specifically to that IP address.

However, if you took down 10.0.0.133, and you tried to access the resource specifically from 10.0.0.133 (i.e. http://10.0.0.133/) you would get an error.

UPDATE:

If you're using Apache VirtualHosts:

<VirtualHost *:80>
DocumentRoot /www/example1
ServerName www.example.com

# Other directives here

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /www/example2
ServerName www.example.org

# Other directives here

</VirtualHost>

This config will allow two sites to use the same IP address and port. If this is how you have your VirtualHosts set up, then VirtualHosts is handling your automatic routing (if you listed both ServerName fields as the same host, theoretically).

You indicated you were using OpenVZ. OpenVZ may allow your sites to run independently, but physically, they're all on the same host. Unless you assign each individual VE their own hostname, and you attempt to access that hostname specifically while it's down, you'll get the expected behavior of the site being up.

For Example, if you assigned a different hostname to one of the OpenVZ/IP Addresses:

10.0.0.133 mybackup.xxx.yy

If you took 10.0.0.133 down, you wouldn't be able to access it from mybackup.xxx.yy anymore, but you would be able to access it from testbackup.xxx.yy (because it goes through the other IP addresses that are still up and associated with testbackup.xxx.yy).

enter image description here

CIA
  • 1,606
  • 2
  • 13
  • 30
  • I think there's a slight misunderstanding here - not that your answer isn't accurate, it's just not quite the question I was asking. To use your nickname metaphor, what I have is several people with the same nickname, not one person with lots of nicknames. The different IP addresses refer to different containers (in effect, different machines), but they all have the same hostname. I only run 1 of them at a time. Is that still the expected behaviour? Does 'something' try each IP in turn until it gets a response? What is the 'something'? Thanks, Dave. – dsl101 Oct 07 '13 at 10:54
  • I'm not sure that made it any clearer. Perhaps you could draw a map to help explain how you have things set up? However, regardless of how many containers you have, if they're all running on the same host/hostname, you could have many IP addresses assigned to the host and anyone attempting to access the host by name will get any one of those IP addresses (if they're up/available). This will only change if you have IP specific applications or filters in place (theoretically). Note: this isn't to be confused with virtualhosts and virtual websites. – CIA Oct 08 '13 at 15:44
  • I edited the OQ 'long version' - does that help? I _am_ using VirtualHost on Apache on the HN. The HN only has 1 external IP, and _all_ subdomains are mapped in DNS to that IP. I can't work out which bit of software effectively picks the 1 working internal IP address from /etc/hosts on the HN when doing the reverse proxying. Does Apache try each entry for a given hostname in /etc/hosts until it finds a working one? Or does it ask some other network component for that? OpenVZ is probably not relevant here - they could be physical servers, but I included it for context. – dsl101 Oct 09 '13 at 08:01
  • See my updates. OpenVZ or VirtualHosts. It doesn't really make a difference if all the IP addresses are associated with the same host (unless your apps are built IP specific). – CIA Oct 09 '13 at 13:24
  • OK - nothing is accessed from the outside by IP - all done by name. I think your last sentence is where the misunderstanding is - they are all _different_ hosts with the same hostname (yes, it's OVZ, so there's really only one physical machine, but they could be separate boxes with different private IPs and the same name). Only one of them is running at any one time. Does that give essentially the same effect? In any case, I'm still not sure exactly which component is doing the 'which IP address is active/responsive' bit in your answer. For example, suppose _all_ of them are running? Who wins? – dsl101 Oct 10 '13 at 09:33
  • Your example shows all those IPs are on the same host with the same hostname. They "could" be different hosts, but they're not. You said they're on the same host. OpenVZ and VirtualHost doesn't make them a separate host; it allows multiple individulalized instances to run on a singular host. (My aside about the public IP was in regards to NATing). You'll run into problems if more than one is up at a time with the same hostname. Every machine needs its own unique name. Otherwise, it's based on NIC/MAC/ARP priority at the routing level. – CIA Oct 10 '13 at 13:23
  • Right - I'd be using host to refer to the OVZ containers, as I'd assumed they are in effect separate 'hosts' - e.g. individual (private) IP addresses, processes, logins etc. I don't think the example would be any different if I'd set up actual physical hosts as described - it was just easier to use OVZ. But I think your last sentence is what I was after, so thanks for persevering! I couldn't tell if it was Apache picking the single responsive host (there I go again), or something lower level - guess that's something at the kernel level? I've marked it answered anyway - thanks again. – dsl101 Oct 10 '13 at 17:53