Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Sorry for the mixed-up title, but let me try to explain better:

We run a hosting solution, which until now has supported shared hosting and VPSes. Easy enough.

We are now getting larger clients which require a more complex setup. We have more or less settled the server-setup itself, which will consist of:

  • 1-2 Frontend Proxy/Load balancing servers
  • 2+ Application servers
  • 1 Database server
  • 1 optional Memcached server

The issue we are dealing with is to agree on a flexible and easy-to-maintain IP setup. So far we've been into VLAN'ing the internal servers in its own subnet, we've though of assigning an official IP to each server, and so on.

What will be the best approach here? Any best practices? Using one official IP on the Frontend server, and then just set up an internal subnet for the servers behind that?

We could then just NAT in any eventual sources required to access for instance the DB server directly over 3306.

share|improve this question

It really would depend on your goals. Would the registration authority in your region hand out the required number of IP addresses without questioning the actual need? Do you need all servers to be accessible without NAT or some kind of tunneling for diagnostic / troubleshooting purposes? Are you using IPv6 where address conservation issues would not matter anyway?

At least the RIPE does encourage the applicants not to use public IPv4 addresses for hosts which do not need public access and use vhosts and load balancers instead in order to conserve the IPv4 address space.

If your thought of segmenting the internal servers into an own VLAN and IP subnet was due to security considerations, then yes, this might make sense in certain cases. You would need to define a threat model and see if there would be a security gain from segmentation that justifies the add-on management overhead for an additional network. But this again is separate from the issue of using public IPv4 addresses or not - you could set up IP filters to match your needs either way.

share|improve this answer

So you want a tall, thin stack, with 2 or 3 single points of failure at the top and bottom. Might I suggest that this will not be the most reliable way of providing the service.

While architecture can be constrained to some extent by the technologies that implement it, you've provided no details of these.

VLAN'ing the internal servers in its own subnet,

WTF? A vlan is not the same same thing as a subnet. While vlans switch slightly faster than IP routing, IME the difference is trivial in comparison to the processing taking place at each tier - and using separate subnets has additional benefits in terms of security. Indeed, if you implement the routing on the nodes themselves with seperate NICs, then there is no slowdown compared with a vlan.

Using one official IP on the Frontend server

Another single point of failure and complexity in managing load balancing. Use at least 2 with round robin DNS or multi-pathing upstream.

directly over 3306

Ah, some useful information at last - it's MySQL. Then it's a no-brainer to run replication, using the machine earmarked as the memcache server as the other node (either as slave in failover or master-master replication). Also, run memcache across both nodes at this tier.

Best approach from here is to go back and start again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.