On 05/02/2013 08:57 AM, Les Mikesell wrote: > On Wed, May 1, 2013 at 4:52 PM, Michael Mol <mikemol at gmail.com> wrote: >> >> Intent is to maintain the old, slow (but has an SLA) connection as a >> fallback, and migrate services to the new connection piecemeal. >> Meanwhile, the same DNS server on the new connection can be, e.g. "ns3". >> The same mailserver can have a new MX on the new connection...likely >> prioritized to it. > > Note that there are more straightforward ways to do this. One is to > pretend you are big enough to have a distributed server farm and > actually have independent servers at the other IPs, even if they are > VMs. This is fairly easy for mostly-static or database-driven web > sites, fairly difficult for apllications that are more statefull but > perhaps possible with a common NFS backend. Another is to have > application-level proxies or load balancers like haproxy, nginx, > apache configured as a reverse-proxy, or even port forwarding with an > xinetd 'redirect' configuration. This loses the source ip from the > application logs, although the http proxys have an option to pass > them. Similarly you could use iptables to source-nat on the > receiving side and forward to a backend server. These all have some > disadvantages, but with separate hosts each having one default gateway > to the internet and static routes for your own local ranges you have a > lot less black magic involved. Actually, this is all stuff (well, except for haproxy) we have implemented. 80-90% of my servers don't even need (and, ultimately, won't have) public IP addresses. (And I still won't need NAT, thank god.) Internally, I'm not far from having things set up as a fluid private cloud with scaleable services. Ultimately, for this to work cleanly, anything which requires a public IP (be it a raw authoritative DNS server or a load balancer) will require an IP on both public subnets. The only blocker right now is getting CentOS to do source-policy routing properly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20130502/16f9aa19/attachment-0005.sig>