Last-mile connection problem
One of our links has been down for two weeks now. It seems the modem at the telco outplant couldn't handle the stress.
Too bad, because that link had just been upgraded. It would've been real nice to test its performance, then we can go rollout one of the link failover solutions we were brewing.
We were planning three separate approaches to the last-mile problem, i.e. how to switch over to a secondary link once the primary goes down. In our case, our primary and secondary links, ideally, should handle the same loads. In reality, though, we have stretched the primary and underutilized the secondary.
The solutions:
But for now, we content ourselves to manually switching the IPs for all the servers and cross our fingers that the propagation would follow through over the weekend. What a lousy hack.
Too bad, because that link had just been upgraded. It would've been real nice to test its performance, then we can go rollout one of the link failover solutions we were brewing.
We were planning three separate approaches to the last-mile problem, i.e. how to switch over to a secondary link once the primary goes down. In our case, our primary and secondary links, ideally, should handle the same loads. In reality, though, we have stretched the primary and underutilized the secondary.
The solutions:
- BGP routing. It's not really feasible in our case since we have piecemeal IP blocks, not the /19 behemoths. Even if we can somehow try private AS numbers, it would be a hassle to blow holes at the provider side for our IPs.
- Concurrent DNS entries. We can have a primary nameserver using the primary link, and a secondary on the other. Problem would be to set the TTL values low enough for clients to refresh in a significantly minimum amount of time once one nameserver fails.
- Using LVS for the various services. This one, so far, is the most attractive solution, and would entail the minimum fuss. We can set the virtual server to have two parallel IPs, set name records for those IPs with appropriate TTLs, and have LinuxDirector either NAT or tunnel services to the real servers, which are then connected to concurrent storage devices for high availabilty. The virtual server, of course, would have a backup.
But for now, we content ourselves to manually switching the IPs for all the servers and cross our fingers that the propagation would follow through over the weekend. What a lousy hack.
Comments
Post a Comment