On 05/02/2013 08:57 AM, Les Mikesell wrote:
On Wed, May 1, 2013 at 4:52 PM, Michael Mol mikemol@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.