Conference paper Open Access

How many planet-wide leaders should there be?

Liu, Shengyun; Vukolic, Marko


Dublin Core Export

<?xml version='1.0' encoding='utf-8'?>
<oai_dc:dc xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
  <dc:creator>Liu, Shengyun</dc:creator>
  <dc:creator>Vukolic, Marko</dc:creator>
  <dc:date>2015-06-03</dc:date>
  <dc:description>Geo-replication becomes increasingly important for modern planetary scale distributed systems, yet it comes with a specific challenge: latency, bounded by the speed of light. In particular, clients of a geo-replicated system must communicate with a leader which must in turn communicate with other replicas: wrong selection of a leader may result in unnecessary round-trips across the globe. Classical protocols such as celebrated Paxos, have a single leader making them unsuitable for serving widely dispersed clients. To address this issue, several all-leader geo-replication protocols have been proposed recently, in which every replica acts as a leader. However, because these protocols require coordination among all replicas, commiting a client's request at some replica may incure the so-called "delayed commit" problem, which can introduce even a higher latency than a classical single-leader majority-based protocol such as Paxos.
In this paper, we argue that the "right" choice of the number of leaders in a geo-replication protocol depends on a given replica configuration and propose Droopy, an optimization for state machine replication protocols that explores the space between single-leader and all-leader by dynamically reconfiguring the leader set. We implement Droopy on top of Clock-RSM, a state-of-the-art all-leader protocol. Our evaluation on Amazon EC2 shows that, under typical imbalanced workloads, Droopy-enabled Clock-RSM efficiently reduces latency compared to native Clock-RSM, whereas in other cases the latency is the same as that of the native Clock-RSM.</dc:description>
  <dc:identifier>https://zenodo.org/record/55067</dc:identifier>
  <dc:identifier>10.1145/2847220.2847222</dc:identifier>
  <dc:identifier>oai:zenodo.org:55067</dc:identifier>
  <dc:relation>info:eu-repo/grantAgreement/EC/H2020/643964/</dc:relation>
  <dc:relation>url:https://zenodo.org/communities/ecfunded</dc:relation>
  <dc:relation>url:https://zenodo.org/communities/supercloud</dc:relation>
  <dc:rights>info:eu-repo/semantics/openAccess</dc:rights>
  <dc:rights>https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode</dc:rights>
  <dc:title>How many planet-wide leaders should there be?</dc:title>
  <dc:type>info:eu-repo/semantics/conferencePaper</dc:type>
  <dc:type>publication-conferencepaper</dc:type>
</oai_dc:dc>
61
33
views
downloads
Views 61
Downloads 33
Data volume 6.0 MB
Unique views 61
Unique downloads 33

Share

Cite as