27
Google_Chubby 论文学习分享 The Chubby lock service for loosely-coupled distributed systems 杭研后台/综合技术组/王公仆

Chubby lock service

  • Upload
    -

  • View
    34

  • Download
    0

Embed Size (px)

Citation preview

Google_Chubby 论文学习分享

The Chubby lock service for loosely-coupled distributed systems

杭研后台/综合技术组/王公仆

Chubby设计概述

v  设计初衷

v  目标:同时为弱关系分布式系统提供粗粒度锁服务与低容量可靠存储; v  接口:提供类似于带有建议性锁的分布式文件系统的接口; v  侧重点:设计主要侧重于可用性与可靠性而非高性能;

v  应用场景

v  被用在通过高速网络互连大量小型计算机组成的松耦合分布式系统中;chubby单元受限使用于一个数据中心或机房,但至少有其一个副本被放置于千里之外;

v  提供锁服务是为了同步客户端的行为以及客户端们对所处的环境信息的变化保持一致;

v  因为首要设计目标是为了可靠性,为超大规模的用户提供服务的可用性,以及易于理解的语义,吞吐量和存储能力是次要考虑因素,所以客户端接口被设计成类似于支持完整文件的读写的简单文件系统,读写时争用建议性锁/如果发生修改文件等事件会有通知机制;

v  Chubby可以帮助开发者处理他们系统中粗粒度的同步问题尤其是leader选举,即从一组等价的服务器集合中选出一个leader。

v  GFS使用chubby锁来选出一个GFS master,BigTable有几种使用chubby方式:进行master选举,帮助master找到它控制的服务器集合,协助客户端找到master。此外,GFS/BigTable还使用chubby来存储它们一部分元数据,作为它们分布式数据结构的根节点,还有一些服务使用chubby在多个服务器间粗粒度地划分任务;

Chubby in GFS/BigTable

Cluster Scheduling Master

handles failover, monitoring

GFS

holds tablet data, logs

Lock service

holds metadata, handles master-election

Bigtable tablet server

serves data

Bigtable tablet server

serves data

Bigtable tablet server

serves data

Bigtable master

performs metadata ops, load balancing

Bigtable cell Bigtable client Bigtable client

library

Open()

Chubby in GFS/BigTable

背景知识 v  分布式系统的⼀一致性问题:在由多个计算机组成的异步系统中,某些计算机可能是不可靠的,如何让可靠的计算机集合在⼀一个值上达成⼀一致,其应⽤用场景如: u  决定是否将⼀一个事务提交到数据库 u  对当前时间的界定达成⼀一致以实现同步化时钟 u  执⾏行分布式算法的下⼀一步 u  选择⼀一个leader节点

v  拜占庭将军问题 :由莱斯利兰伯特提出的点对点通信中的基本问题,在分布式计算上不同的计算机通过讯息交换,尝试达成共识;但有时候系统上协调计算机 或成员计算机 可能因系统错误并交换已出错的讯息,导致影响最终的⼀一致状态的确定。

v  FLP结论:在不考虑拜占庭类型的错误并假设消息系统是可靠的情况下(能够⼀一次性正确的传送所有的消息)然⽽而即使有这些假设,如果⼀一个进程恰好在⼀一个⾮非常不合适的时间停⽌止运⾏行,也会导致分布式提交协议⽆无法达到⼀一致。因此如果没有关于计算环境的更进⼀一步的假设或者关于所能容忍的错误类型更多的限制,这个问题根本就没有健壮的解决⽅方案。针对异步分布式系统⼀一致性问题的任何协议都有不可终⽌止的可能性,即使是在只有⼀一个出错进程的情况下。与此相反在同步系统的情况下的拜占庭将军问题却的确存在解。

v  Paxos协议:分布式系统中的节点通信存在两种模型:共享内存和消息传递。基于消息传递通信模型的分布式系统不可避免的会发⽣生以下错误:进程可能会慢、crash、重启,消息可能会延迟、丢失、乱序,重复(在基础 Paxos 场景中先不考虑可能出现消息篡改即拜占庭错误的情况)在⼀一个可能发⽣生上述异常的分布式系统中如何就某个值达成⼀一致,保证不论发⽣生以上任何异常,都不会破坏决议的⼀一致性。⼀一个典型的场景是在⼀一个分布式数据库系统中,如果各节点的初始状态⼀一致,每个节点都执⾏行相同的操作序列,那么他们最后能得到⼀一个⼀一致的状态。为保证每个节点执⾏行相同的命令序列,需要在每⼀一条指令上执⾏行⼀一个“⼀一致性算法”以保证每个节点看到的指令⼀一致。⼀一个通⽤用的⼀一致性算法可以应⽤用在许多场景中,是分布式计算中的重要问题。 Google Chubby服务的创建者Mike Burrows说过“世上只有⼀一种⼀一致性协议,那就是paxos”—所有其他的⽅方法都只是paxos的⼀一个特化版本。paxos由Leslie Lamport1990年提出的⼀一种基于消息传递且具有⾼高度容错特性的⼀一致性算法 。

Paxos原理

Paxos原理

Chubby论文学习分享

p  Chubby的设计考虑

p  Chubby中的Paxos

p  Chubby的扩展机制

p  Chubby的应用情况

p  相关研究

p  论文总结

Chubby的设计考虑 p  Centralized Lock Service Vs Client Paxos Library v  中心化的锁服务的优缺点

u  系统因初始设计未考虑高负载和高可用性而当客户急速增多时需加入一致性协议,使用中心化锁服务维护已有代码结构与通信模式会更简单;

u  锁服务因一致性客户端缓存机制可承担name service角色,为需要leader选择服务的应用提供选举结果通知机制,减少客户端依赖服务器数量又使协议一致性得到共享;

u  基于锁的接口实现更为开发者所熟知,客观上减少了开发者对分布式决策使用可靠性的思考,因为很少有人会考虑机器失败时对异步通信系统锁带来的影响;

u  Chubby单元通常有5个副本能达到更高的可用性,锁服务实际上提供了一种通用的选举机制,它允许客户端系统在其自身成员存活数小于半数时仍可以正确地作出决策,上述问题也非提供另一个“一致性服务”所能全部解决;

u  其实Google内部也为开发者提供了一个独立于chubby的客户端Paxos库,这样仅依赖命名服务器,且开发者有一个标准实现框架(假定服务可以以状态机形式实现);

v  关键性设计

u  选择锁服务的形式而非客户端库或一致性服务形式; u  提供小文件来允许新选出的master公布自身及参数,而非创建和维护另一个服务; u  一个通过chubby文件发布其master的服务可能有成千上万的客户端,因此必须允许这

些客户端查看这个文件又不需要太多的服务器; u  客户端和master的副本们需获知master的改变因此需要一种事件通知机制以避免轮询; u  尽管事件通知机制客户端不必周期轮询master ,但因服务于众多开发者,客户端的

chubby小文件缓存也是必要的,否则对master访问还是过于频繁; u  开发者可能会被非直观的缓存语义搞晕,所以客户端使用一致性缓存; u  还需要提供访问控制在内的安全机制,以免人财受损;

p  Coarse-Grained Vs Fine-Grained Chubby是为粗粒度的应用而设计,比如应用可能使用锁来选举一个master,该master会在

相当长的时间(数小时甚至数天)来处理数据访问请求。而细粒度锁持有时间会非常短(秒级甚至毫秒级别),这两种不同应用场景对锁服务器会提出不同的要求,chubby并不适用于细粒度的应用场景,但客户端根据自己应用特点定制细粒度锁是很简单的;

p  粗粒度锁带给锁服务器的负载很低; 粗粒度时锁的获取率与客户端应用程序的事物发生率只是弱相关,粗粒度所很少产

生锁获取请求,一个锁从客户端到另一个客户端可能需要高昂的恢复处理,所有人们不希望锁服务器的故障恢复造成锁的丢失。因此,粗粒度的锁能够经历锁服务器的失败而继续有效是很有用的。

p  细粒度锁带给锁服务器的负载很高; 即使锁服务的短暂的不可用也可能导致许多客户端挂起。因为锁服务上的事务频率

将随着所有客户端的事务频率之和一起增长,性能和随意增加新服务器的能力十分重要。不需要在锁服务器失败之间维持锁可以减少锁定的开销,这是优势;频繁地丢弃锁也不是一个很严重的问题,因为锁只被持有一段很短的时间。(客户端必须准备好在网络分离期间丢失锁,因此锁服务器故障恢复造成的锁的丢失不会引入新的恢复路径。

p  客户端根据自己应用特点定制细粒度锁 一个应用程序可能将它的锁划分成组,并使用Chubby的粗粒度锁将这些锁分组分配

给应用程序特定的锁服务器。维护这些细粒度的锁只需要很少的状态,这些服务器只需要持有一个不常变的、单调递增的请求计数器,这个请求计数器不会经常被更新。客户端能够在解锁时发现丢失了的锁,并且如果使用了一个简单定长的租期(lease),其协议将会简单高效。这种模式的 重要的收益是我们的客户端开发者对他们的负载所需的服务器的供应负责,也将他们从自己实现协同的复杂性中解放出来。

Chubby的设计考虑

p  Chubby有两个主要组件,它们之间通过RPC进行通信:一个服务器,一个客户端应用程序需要链接的库;

u  一个Chubby单元由一组称作副本集的服务器(五个)组成,按降低关联的可能性来放置(例如分别放在不同的机架)它们使用分布式一致的协议来选举一个Master,Master必须从副本集得到多数投票,并得到副本集在一个持续数秒的被称为master租期(lease)的时间段内不再选举另一个不同的Master。只要Master继续赢得大多数投票,这个租期就会周期性地被副本集刷新。

u  副本集维护着一个简单数据库的备份集,但是只有master发起对数据库的读写。其他的所有副本简单地从master复制使用一致性协议传送的更新;

u  客户端们通过发送master位置请求给列在DNS中的副本集来查找master。非master的副本返回master的标识来回应这些请求。一旦一个客户端定位到master,它将所有请求指引到该master,直到该master停止回应或者指明自己不再是master。

Chubby的系统架构

u  写请求被通过一致性协议传播给所有副本,这些请求在写入达到Chubby单元中的多数副本时被答谢确认。

u  读请求有master独自满足,这样是安全的,只要master租期没有过期,因为没有别的master可能存在。

u  如果一个master失败了,其他的副本在他们的master租期到期时运行选举协议; u  如果一个副本失败了并且在几个小时内没有恢复,一个简单的替换系统从一个空闲

池选择一台新的机器,并在其上启动锁服务器的二进制文件(binary)。然后它将更形DNS表,将失败了的副本的IP替换为新启动的启动的IP。

u  当前master周期性地轮询DNS并 终注意到这个变化,然后它在该Chubby单元的数据库中更新单元成员列表,这个列表在所有成员之间通过常规的复制协议保持一致。

u  与此同时,新的副本取得存储在文件服务器上的数据库备份和活跃副本的更新的组合。一旦新副本处理了一个当前master在等待提交的请求,新的副本就被许可在新master的选举中投票。

Chubby的系统架构

Chubby中的Paxos 单个Chubby副本结构: u 容错日志——对数据库正确性提供重要支持,一致性由Paxos算法保证,副本之间通过特定的Paxos协议通信,同时本地文件中保存与Chubby中相同的日志数据 ; u 容错数据库——快照(Snapshot)和记录数据库操作重放日志(Replay-log)每一次的数据库操作 终都将提交到日志中;本地文件中也保存着一份数据库数据副本; u Chubby构建在这个容错的数据库之上,Chubby利用这个数据库存储所有的数据。Chubby的客户端通过特定的Chubby协议和单个的Chubby副本进行通信 ;

单个Chubby Cell结构

Chubby中客户端使用Paxos算法流程: u 选择一副本为协调者(primary) u 协调者从客户提交的值中选择一个,accept消息广播给所有的副本,其他的副本收到广播后,选择接受或者拒绝这个值,并将决定结果反馈给协调者; u 协调者收到大多数副本接受信息后,认为达到了一致性,接着向相关副本发送一个commit消息 ;

p  Chubby文件 Chubby本质是一个分布式存储大量小文件的文件系统,所有操作都在文件基础上完成:

Ø  Chubby 常用的锁服务中,每一个文件就代表一个锁,用户通过打开、关闭和读取文件,获取共享(Shared)锁或独占(Exclusive)锁;

Ø  选举主服务器过程中,符合条件的服务器都同时申请打开某个文件并请求锁住该文件;

Ø  成功获得锁的服务器自动成为主服务器并将其地址写入这个文件夹,以便其他服务器和用户可以获知主服务器的地址信息;

p  Chubby的文件系统和UNIX类似

例如在文件名“/ls/foo/wombat/pouch”中,ls代表lock service,这是所有Chubby文件系统的共有前缀;foo是某个单元的名称;/wombat/pouch则是foo这个单元上的文件目录或者文件名

p  Google对Chubby做了一些与UNIX不同的改变

例如Chubby不支持内部文件的移动;不记录文件的 后访问时间;另外在Chubby中并没有符号连接(Symbolic Link,又叫软连接,类似于Windows系统中的快捷方式)和硬连接(Hard Link,类似于别名)的概念

p  具体实现 文件系统由许多节点组成,分为永久型和临时型,每个节点就是一个文件或目录。节

点中保存着包括ACL(Access Control List,访问控制列表)在内的多种系统元数据

Chubby文件系统

p  元数据包含以下四种单调递增64位编号 Ø  实例号:新节点实例号必定大于旧节点的实例号 Ø  内容生成号:文件内容修改时该号增加 Ø  锁生成号:锁被用户持有时该号增加 Ø  ACL生成号:ACL名被覆写时该号增加

p  文件句柄: 用户打开某个节点的同时会获取一个类似于UNIX中文件描述符(File Descriptor)的句柄,在文件操作中,用户可以将句柄看做一个指向文件系统的指针,这个句柄由以下三个部分组成

Ø  校验数位:防止其他用户创建或猜测这个句柄 Ø  序号:确定句柄由当前还是以前的主服务器创建 Ø  模式信息:用于新的主服务器重新创建一个旧句柄

p  锁与序号:为防止分布式系统处理锁事件过程中存在消息乱序现象,从而导致数据不一致问题,Chubby针对性地引入了sequencer的概念,sequencer实际上就是一个序号,只能由锁的持有者client在获取锁时向Master发出请求来获得。在实际执行中为了避免所有的通信都使用序号带来系统开销,Chubby只允许涉及锁的操作才用,其他操作一概不用。在primary服务器有效期间该值不变,通过checksequencer验证primary有效。

Chubby文件系统

Chubby文件系统

函 数 名 称 作 用

Open() 打开某个文件或者目录来创建句柄

Close() 关闭打开的句柄,后续的任何操作都将中止

Poison() 中止当前未完成及后续的操作,但不关闭句柄

GetContentsAndStat() 返回文件内容及元数据

GetStat() 只返回文件元数据

ReadDir() 返回子目录名称及其元数据

SetContents() 向文件中写入内容

SetACL() 设置ACL名称

Delete() 如果该节点没有子节点的话则执行删除操作

Acquire() 获取锁

Release() 释放锁

GetSequencer() 返回一个sequencer SetSequencer() 将sequencer和某个句柄进行关联

CheckSequencer() 检查某个sequencer是否有效

常用句柄函数及其作用

p  Chubby还使用了一致性客户端缓存(Consistent Client-Side Caching)技术,目的是减少通信压力,降低通信频率 ;

u  在client保存一个和单chubby cell上数据一致的本地缓存,需要时client可以直接从缓存中取出数据而不用再和主服务器通信;

u  当某个文件数据或者元数据需要修改时,master(primary chubby cell)首先将这个修改阻塞,然后通过查询主服务器自身维护的一个缓存表,向对修改的数据进行了缓存的所有客户端发送一个无效标志(Invalidation);

u  Clients收到这个无效标志后会返回一个确认(Acknowledge),master在收到所有的确认后才解除阻塞并完成这次修改 ,该过程的执行效率非常高,仅仅需要发送一次无效标志即可,因为对于没有返回确认的节点,master会直接认为其未缓存待修改数据。

u  Chubby用ACL保障安全。系统有三种ACL名:写ACL名/读ACL名/变更ACL名,只要不被覆盖写,子节点都是直接继承父节点的ACL名,ACL同样被保存在文件中,它是节点元数据的一部分,用户在进行相关操作时首先需要通过ACL来获取相应的授权。

u  用户chinacloud提出向文件cloud中写入内容请求,cloud首先读取自身的写ACL名fun,接着在fun中查到了chinacloud这一行记录,于是返回信息允许chinacloud对文件进行写操作,此时chinacloud才被允许向CLOUD写入内容。其他操作与此类似.

Chubby的客户端缓存

chinacloud CLOUD fun

……

……

chinacloud ①请求写文件

②读取写 ACL名 ③查询

④成功查到 允许写入

⑤成功写入

v  Chubby 会话⽤用来保持主服务器与客户端之间的联系。会话通过keep alive的握⼿手机制维持。每个会话都有⼀一个与之相关的租约(租期内master保证不单⽅方⾯面结束会话)。

v  斜向上的箭头是client发给master(chubby cell)的keepalive请求,向下的箭头是master回应; v  M1/M2/M3表⽰示不同maseter有效会话租约期,C1/C2/C3表⽰示client对当前会话有效租约期做出的⼀一个估计,⽐比M1/M2/M3要保守,master对会话设定租约或续约发⽣生在会话建⽴立时/master故障恢复时/响应keepalive请求时。Master可任意延⻓长租约(12s过载时更⻓长)。

v  Keepalive由client周期(7s)发送,除⾮非client通知master结束会话否则⼀一直有效,即client的句柄/锁/缓存数据都是有效的,master回复client的响应有两个⽅方⾯面功能,⼀一是延⻓长会话租约有效期,⼆二是携带事件信息通知client更新,主要事件包括⽂文件内容被修改,⼦子节点被增加/删除/修改,主服务器出错,句柄失效等;通常情况下会话租约会及时得到延⻓长,事件也会及时通知到client;

v  会话在client第⼀一次与master连接时建⽴立,会话终⽌止发⽣生有两种可能,client正常关闭或会话已经空闲(⼀一分钟内都没有打开的句柄或相关调⽤用,client会显式地调⽤用关闭会话)。由于系统可能失效引⼊入故障处理很有必要主要指会话租约过期和master故障。

Chubby的会话与保活

v  当client看到的租约过期失效(C2)时,client将会进入宽限期(grace period)开启一个针对宽限期的计时器(45s),同时client清空并禁用客户端缓存,chubby库向应用程序发送一个jeopardy事件,阻塞所有上层应用程序调用以使得在能确认会话状态之前应用程序能保持静默;

v  终一个新的master通过paxos协议成功选举出来了,新master正常工作后先使用一个相对保守租期M3(相对于旧master与该client间曾有过的租期),client找到新master后发Keep-Alive请求4,但会被回复5拒绝(因master epoch不对,拒绝消息中含正确的),client使用新的epoch重试6会收到正常响应7,7允许客户端再次扩展其租约C3,并结束危险期会话进入safe阶段;Grace period时长通常会大于C2结束到C3开始之间的时间间隔(如果违反该约束就失败通知应用程序),这样客户端看到的只是master响应出现了延迟而已。

v  如果客户端持有一个文件句柄H,当会话过期是H上的所有操作都会失败(除close/poison),通过这种方式保证网络异常时H上的操作序列执行序列唯一且H为committed状态。

Chubby的故障恢复

新当选的master需重建前任master状态通过:

Ø  一部分通过读取保存在硬盘上的持久化数据(通过普通数据库备份协议备份) Ø  一部分通过从客户端获取状态

Ø  一部分在通过相对保守的估计

数据库会记录每个会话,持有的锁以及临时文件, 终达到与前任一致的内存状态;

新当选master执行流程:

①  首先选择epoch number,以后每次回话都会出示该编号,防止与旧master混淆;

②  新master响应客户端的master定位请求,开始阶段并不处理会话相关操作;

③  为曾记录在案会话与锁建立内存数据结构并将租期延至前会话曾使用租期 大值;

④  Master开始让客户端执行keep alive,但仍不处理其他会话操作;

⑤  为每个会话产生一个故障恢复事件,让客户端刷新缓存,同时警告client某些event可能已经丢失;

⑥  Master等待client针对故障恢复消息的响应,或者会话超时过期;

⑦  Master开始处理各种操作;

⑧  关于客户端使用一个先于故障恢复点创建的句柄,又或者已经被关闭?

⑨  稍长一段时间之后,Master删除那些没有被打开句柄的临时文件。

Chubby的故障恢复

v  Chubby的第一个版本采用多副本的Berkeley DB。Berkeley DB提供了B树结构,可以映射字节串的关键字到任意的字节串的值。Google提供关键字比较接口可以优先按照路径名中的组件编号进行排序,使得节点既可以按照路径名得到关键字,同时在排序中兄弟节点又可以相邻。由于Chubby中不使用基于全路经的权限检查,所以每个文件访问进行一次数据库查询就可以了。

v  Berkeley DB使用分布式一致性协议在一系列的机器上复制数据库日志。只要添加了主服务器的租约功能就符合Chubby的设计了,这使得实现起来非常直观。

v  虽然Berkeley DB的B树代码已经较为成熟且被广泛使用,但副本代码存在奉献,google自己实现了一个简单的数据库,采用预写日志和快照机制,与Birrell等的设计类似。

v  Chubby数据库日志使用分布式一致性协议分发在所有副本上。因为只使用了Berkeley DB很少的特性,所以google的重写在整体上极大的简化了系统;例如chubby只需要原子性操作但不需要通用的事务。

v  每隔几个小时每个Chubby cell的master节点就把它的数据库当前快照备份到不同数据中心的GFS文件服务器。不同数据中心的分离既可以避免数据中心失效带来的数据丢失,又避免了备份的循环依赖,因为在同一数据中心内的GFS节点可能会依赖Chubby cell来选举它的主节点。

v  备份不仅可以用于灾难恢复,还提供一种方式用于初始化哪些新被替换的副本,而不会增加那些正在服务中的副本的通信负载。

Chubby的数据库实现与备份

v  Chubby允许一系列文件从一个节点镜像到另一个节点。镜像的速度很快,因为文件尺寸较小,而且事件的机制允许在一个文件添加、修改、删除后立即通知镜像模块。假设没有网络问题,文件修改会在1s内镜像到世界范围的所有服务器。如果一个镜像不能访问,那么在连接修复前它保持不变。更新的文件会通过他们的识别码进行识别。

v  镜像经常用于拷贝配置文件到全世界不同的计算集群。一个特殊的节点名为global,包含一个子树/ls/global/master,它被镜像到所有其他Chubby节点的/ls/cell/slave子树上。全球节点很特殊是因为它的五个子节点分布在世界各地,这样方便全球各组织机构的访问。

v  global节点镜像的文件当中还包括Chubby自己的访问控制列表,Chubby和其他系统的宣传文件,方便用户接入数据存储的指针,如Bigtable节点,以及许多其他系统的配置文件。

Chubby的镜像

Chubby的扩展机制 p  Chubby为提高可扩展性目前已经采取和计划采取的措施有提高主服务器默认

的租约期/使用协议转换服务将Chubby协议转换成较简单的协议/客户端一致性缓存/代理(Proxy)和分区(Partition)技术等;

v  创建任意数量的Chubby节点客户端几乎总是可以使用 近的chubby cell(由DNS得到)避免对远程机器的依赖。典型部署是一个Chubby节点对应一个数千台机器的数据中心;

v  当负载过高时主服务器可以把租约时间由默认的12s增加到60s左右,减少了维持活动的RPC数量(目前为止维持活动的开销比较大,而且负载过高的服务器较容易出现该问题,客户端对其它调用的延迟变化非常不敏感);

v  client缓存文件数据/元数据/文件丢失以及打开的句柄来减少与服务器交互负载;

v  使用协议转换服务器把Chubby协议转换为比较不复杂的协议如DNS等。

v  代理和分区这两种机制可以让Chubby的规模进一步扩展,在具体实践中还没有使用它们,但是已经设计完成,并有可能近期投入到使用。代理通信两端都使用可信代理进行通信,可减少服务器负载,分区将不同的名字空间划分到不同的chubby cell中去,一个chubby cell由N个分区组成,每个分区有一个master和一组副本,每个分区独立处理属于自己的请求调用,分区可以将任意分区cell降至1/N但并减少keepalive总量,如果chubby需要处理更多客户端,建议代理和分区一起使用。

Chubby应用情况 v  许多文件用于名字服务

v  配置文件/访问控制和元数据文件十分常见

v  平均10个客户端共用一个缓存的文件

v  Negative caching非常明显

v  很少有客户端会持有锁,共享锁用得很少,锁服务主要用于master选举和在多副本上分配数据与设计一致

v  RPC流量主要是keepalive,有少量读操作(client缓存未命中)极少量的写和获取锁操作

v  教训 v  开发者很少考虑可用性 v  细粒度锁问题可以被忽略 v  糟糕的API设计会产生无法预料的结果 v  RPC的使用影响了会话协议(keepalive用于

刷新会话租约也用于传递事件和缓存失效通知client必须先应答失效通知才能刷新租约),TCP在网络高负载时有拥塞回退机制,导致高负载时大量会话丢失,所以好能基于UDP发keepalive,基于TCP有一

个GetEvent的RPC进行事件和缓存失效通知。Keepalive仍含有未回复事件列表保障事件都能得到确认

Chubby与相关工作对比 v  Chubby不同于诸如Echo或者AFS这样的分布式文件系统:客户端不会读、写及存储大量数据,也

不期望高吞吐率,也不要求缓存数据的低延迟,但希望具有一致性,可用性及可靠性,在性能不是那么重要的情况下这些属性就比较容易达到。

v  因为Chubby的数据库很小因此我们能在线存储它的多个拷贝(通常有5个副本及一些备份)。每天我们会进行多次备份,并且每隔几个小时就会通过数据库状态的checksum在副本之间进行比较。通过对普通文件系统所需的性能及存储需求上的弱化,允许我们可以通过一个Chubby master为成千上万的客户端提供服务。通过提供一个很多客户端可以共享信息及协调工作的中央节点,解决了系统开发者所面对的一类问题。 

v  我们只选择了Boxwood的锁服务器来进行比较,因为它是 近设计的,同时也旨在用于松耦合的环境中。

v  Chubby实现了锁,一个可靠的小文件存储系统,一个会话/租约机制。Boxwood将这些分成了三块锁服务、Paxos服务、一个独立的失败检测服务。

v  因为是面向不同的期望应用,这两个系统的默认参数有着显著的不同:每个Boxwood失败检测器每隔200ms会与客户端通信一次超时时间是1s;Chubby的默认租约时间是12s,KeepAlive每7s进行一次。

v  Boxwood的子部件使用2个或者3个副本来实现可用性,而我们通常在每个单元中使用5个副本。一个更有趣的区别是Chubby引入的宽限期(grace period) 而Boxwood没有这个。这种区别是两种系统关于规模及出错概率的不同期望所导致的。尽管master的故障恢复很少发生但是一个Chubby锁的丢失对于客户端来说是很昂贵的。

v  Chubby锁是重量级的,需要sequencer来保证外部资源的安全,而Boxwood的锁是轻量级的,主要是为了在Boxwood内部使用。

总结

v  Chubby系统提供粗粒度的锁服务,并且基于松耦合分布式系统设计可靠的存储。软件开发者不需要使用复杂的同步协议,而是直接在程序中调用chubby的锁服务,来保证数据操作的一致性。这种锁是建议性的,而不是强制性的锁,具有更大的灵活性。

v  Chubby系统提供档案文件,存储服务的参数及相关信息,而不需要建立并维护另一个服务。同时在RAM中存储数据,支持大规模用户访问文件。客户端缓存数据,减少对主服务器的访问量。为了方便用户,使用一致性缓存。主服务器通过通报机制,定期向客户端发送更新消息。

v  Chubby已经广泛用于名字服务及存储配置信息。 它的设计基于人们所熟知的想法:用于多副本容错的分布式一致性算法,保持了简单语义的用于降低服务端负载的客户端一致性缓存机制,实时性的更新通知,类文件系统接口。我们通过使用缓存机制、协议转换服务器简化负载,来使得单个Chubby实例可以扩展到数万个客户端的规模。未来我们还希望通过代理和partitioning来增加扩展性。

v   Chubby已经成为Google首要的内部名字服务;它为很多系统(比如MapReduce)提供了一种通用的协调机制;存储系统GFS和Bigtable使用Chubby来从多个冗余副本中选举一个primary;而且它也是那些需要高度可用性的文件的标准存储设施,比如访问控制列表。

参考文献 v  PDF The Chubby lock service for loosely-coupled distributed systems v  刘杰 《分布式系统原理》 v  邓侃 北航云计算公开课PPT v  刘鹏 《云计算》 v  phylips@bmy http://duanple.blog.163.com/blog/static/7097176720112643946178/

Q/A