Logically Centralized, Physically Distributed
-
Upload
violet-best -
Category
Documents
-
view
16 -
download
0
description
Transcript of Logically Centralized, Physically Distributed
![Page 1: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/1.jpg)
Logically Centralized, Physically Distributed
Mark Stuart Day
Cisco Systems
![Page 2: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/2.jpg)
Standard disclaimer
No matter what I say in this talk, I’m not making any Lotus product commitments.
Cisco
![Page 3: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/3.jpg)
Outline
• What people want
• What people can have
• An ancient example: – Replicated mail repository
• A recent example:– Content distribution network
• Conclusions
![Page 4: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/4.jpg)
What people want
• Single name/location for single logical service
• Service never goes down
• Service grows/shrinks smoothly
![Page 5: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/5.jpg)
What people can have
• Single name/location for single logical service
• Service never goes down
• Service grows/shrinks smoothly
• Occasional weird errors that violate user expectations
![Page 6: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/6.jpg)
Some ancient history
MIT-LCS-TR-376, Date: May 1987 REPLICATION AND RECONFIGURATION IN A DISTRIBUTED MAIL REPOSITORY Author(s): Day, M.S. Pages: 110 Price: $18.00AD Number: A186967 Keywords: data replication, software reconfiguration, availability, reliability, scalable systems, distributed programs, electronic mail repositories, programming languages
![Page 7: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/7.jpg)
Mail system architecture(think of Grapevine)
Mailbox 1
Mailbox 2
Mailbox 3
Mailbox 4
Client
Directory
![Page 8: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/8.jpg)
Highly available email
Mailbox 1
Mailbox 2
Mailbox 1
Mailbox 2
Mailbox 1
Mailbox 2
Client
Directory
![Page 9: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/9.jpg)
How did it work?
• Systems success– Nice capability for quorum adjustment– New directory algorithm for deletions– Cool dynamic reconfiguration
• User failure– “What do you mean I can’t delete that
message?”– “Where’s that message gone?”
![Page 10: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/10.jpg)
A recent example:Content distribution networks
• Akamai, Digital Island, Mirror Image, Adero, …
• $Millions in revenue
• $Billions in market capitalization
• Might be worth knowing something about
![Page 11: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/11.jpg)
The bad old days (without content distribution)
ClientOriginServer
GET some/piece/o/content
![Page 12: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/12.jpg)
New and improved (with content distribution)
ClientOriginServer
DeliveryNode
DeliveryNode
DeliveryNode
RequestRouter
RequestRouter
ContentRouter
ContentRouter
GETGET
![Page 13: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/13.jpg)
Virtues
• Client unchanged
• Origin server mostly unchanged– Content URLs may be modified
• Add delivery nodes transparently
• Move content around transparently
![Page 14: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/14.jpg)
Caveats
• Lots of detail missing– Request routing: HTTP redirection, DNS
interception, IP hijacking– Content routing: application-level multicast, IP
multicast
• Both request routing and content routing are nontrivial problems
![Page 15: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/15.jpg)
Weird user-visible errors
• Routed to failed box– Content fails to appear– Depending on routing/caching, maybe no
content from that domain ever appears again for that client
![Page 16: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/16.jpg)
Making weird errors into not-so-weird errors
• Deploy “next-click failover”– Delivery nodes clustered into “supernodes”
with switch– Supernode monitors failures– IP addresses of failed nodes remapped onto live
nodes
• Result is similar to common Web behavior– “What the hey?” [click] “Oh, OK.”
![Page 17: Logically Centralized, Physically Distributed](https://reader035.fdocuments.in/reader035/viewer/2022072016/5681332b550346895d9a1f47/html5/thumbnails/17.jpg)
Conclusion
• People want something that’s logically centralized, physically distributed
• But they don’t want the weird errors that come with distribution
• A great thing about the Web:– People are already used to some weird errors