15-replication

15-replication - Replication Howd we get here? Failures...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Replication Howd we get here? Failures & single systems; fault tolerance techniques added redundancy (ECC memory, RAID, etc.) Conceptually, ECC & RAID both put a master in front of the redundancy to mask it from clients -- ECC handled by memory controller, RAID looks like a very reliable hard drive behind a (special) controller Simpler examples... Replicated web sites e.g., Yahoo! or Amazon: DNS-based load balancing (DNS returns multiple IP addresses for each name) Hardware load balancers put multiple machines behind each IP address (Diagram. :) Read-only content Easy to replicate - just make multiple copies of it. Performance boost: Get to use multiple servers to handle the load; Perf boost 2: Locality. Well see this later when we discuss CDNs, can often direct client to a replica near it Availability boost: Can fail-over (done at both DNS level -- slower, because clients cache DNS answers -- and at front-end hardware level) But for read-write data... Must implement write replication, typically with some degree of consistency Important ?: What consistency model? Just like in Flesystems, want to look at the consistency model you supply R/L example: Google mail. Sending mail is replicated to ~2 physically separated datacenters (users hate it when they think they sent mail and it got lost); mail will pause while doing this replication. Q: How long would this take with 2-phase commit? in the wide area? Marking mail read is only replicated in the background - you can mark it read, the replication can fail, and youll have no clue (re-reading a read email once in a while is no big deal) Weaker consistency is cheaper if you can get away with it. Strict transactional consistency (you saw before) sequentially consistent : if client a executes operations {a1, a2, a3, ...} , b executes {b1, b2, b3, ...}, then you could create some serialized version (as if the ops had been performed through a single server) a1, b1, b2, a2, ... (or whatever) executed by the clients using a central server Note this is not transactional consistency - we didnt enforce preserving happens-before. Its just per-program ailure model Well assume for today that failures and disconnections are relatively rare events - they may happen pretty often, but, say, any server is up more than 90% of the time....
View Full Document

Page1 / 8

15-replication - Replication Howd we get here? Failures...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online