1. Fine-Grained Failover Using Connection Migration Alex C. Snoeren, David G. Andersen, Hari Balakrishnan MIT Laboratory for Computer Science

2. The Problem Servers Fail. More often than users want to know… ClientContent server

3. Solution: Server Redundancy Use a healthy one at all times.

4. 1.Health Monitoring 2.Server Selection 3.Connection Resumption Failover Components

5. Today’s Replication Technology DNS/Content Routing Wide-area replication  Need client awareness Layer 4/Web Switches Transparent, possibly mid-stream failover  Requires co-location DNS Web Switch

6. Wide area replication  Yet somehow synchronize replica servers Transparent failover  Enable other servers to continue connections Ideal Technology

7. Stream Mapping  Infer application state from transport layer information Connection Migration  Transparently hand off sessions between servers Migrate Architecture Stream Mapper

8. Stream Mapping HTTP 1.1 200 OK Content-Length: 328987... Content-Type: video/mpeg GET /StreamingContent.mpg HTTP/1.1 Client: Server Response: Stream Map: TCP SeqNo 083346 TCP ISS 083521 ClientObject (URL)Offset (TCP SeqNo) 128.89.3.24:4234/StreamingContent.mpg083346

9. Anatomy of Failover Client Support Group Initial Connection Migrated Connection

10. Support Groups Set of partially mirrored servers  All servers able to provide same content  Can be topologically diverse Synchronize on per-connection basis  Servers need not be complete mirrors  Connections from a failed server can be handled by a different support server  Connections may have distinct support groups

11. Soft State Synchronization Synchronize within support groups  Periodic advertisements  Advertise client application object requests  Communicate initial transport layer state Only initial state need be communicated  Current info inferred from transport layer  Clients will reject redundant migrates from stale support servers

12. TCP Connection Migration 1.Initial SYN 2.SYN/ACK 3.ACK (with data) 4.Normal data transfer 5.Migrate SYN 6.Migrate SYN/ACK 7.ACK (with data) clientserver

13. TCP Connection Migration 1.Initial SYN 2.SYN/ACK 3.ACK (with data) 4.Normal data transfer 5.Migrate SYN 6.Migrate SYN/ACK 7.ACK (with data) clientserver

14. TCP Connection Migration 1.Initial SYN 2.SYN/ACK 3.ACK (with data) 4.Normal data transfer 5.Migrate SYN 6.Migrate SYN/ACK 7.ACK (with data) clientserver failover server 545968:546414(536) ack 533526 SYN 533525:533525(0) ack 545968 current SYN 083521:083521(0) (migrate T, R) stale

15. Implementation Server App Client Stream Mapping Wedges Software “Wedge”  Stream Mapping  Synchronization Wedge

16. Wedge Overhead 1000 10000 100000 1e+06 1e+07 110100100010000 Microseconds per request Request size (Kbytes) Wedge Direct

17. Experimental Topology Client initiates a transfer to A… Linux/Apache 1.3 then migrates to B… and back to A… 128Kbs links

18. Varying Oscillation Rates 0 100000 200000 300000 400000 500000 600000 700000 800000 900000 1e+06 0102030405060 Goodput (bytes) Time (secs) No Oscillations 10 sec 12 sec 2 sec 5 sec

19. Benefits & Limitations Enable wide area server replication  Low server synchronization overhead  Infer current state from transport layer Robust even under adverse loads  Health monitors can be overly reactive  Gracefully handle cascaded failures Leverages connection migration  Requires modern transport stack

20. Software available on the web: http://nms.lcs.mit.edu/software/migrate Networks and Mobile Systems