On 05/02/2013 08:57 AM, Les Mikesell wrote: > On Wed, May 1, 2013 at 4:52 PM, Michael Mol <mike...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
