五千年(敝帚自珍)

主题:【原创】闲话Google集群 [6] 同步的苦恼 -- 邓侃

共:💬33 🌺52
全看分页树展 · 主题
家园 【原创】闲话Google集群 [6] 同步的苦恼

[1] 引子

[2] 存在的理由

[3] 布局

[4] 数据流和控制流的分离

[5] 同步的诀窍

[6] 同步的苦恼

前些时间,有人拿了本国内被禁的“晚年周恩来”,问我要不要读,我回绝了。周公的传记我通常不读,原因是周公太完美了,他是神。神可以被崇拜,但是不可以用来怡情。关于小林元帅的文章,我几乎从不放过,即便在很忙的时候,熬夜也读。小林从大雄走向大奸,不仅褒贬参半,而且争论颇热闹。

做学问也类似。教科书适合催眠,只有俯首帖耳消化吸收的被动,没有激扬文字指点江山的豪情,不打瞌睡不符合人性。读论文有趣得多,趣味在于多数论文只是一家之言。他可以宣扬他的观点,你可以指指点点评头论足,甚至可以另立山头同台打擂。

有关Google集群的论文比较有趣,原因有三,1. Google集群是当今世界规模最大,实际运行效果最好的集群;2. Google的同志们年轻朴实,行文朴实,有啥说啥,不拿一大堆数学公式或者半文不古的术语来忽悠人;3. Google集群并不十全十美,我们大快朵颐消化吸收的时候,不必俯首帖耳,吃饱喝足了,抹抹嘴,说,姜还可以多放些,葱最好打结,这样汤的味道会更厚实。

前一节讲到,当client向某个Chunk-server备份小组存放文件时,GFS规定的工序分7步。看似复杂,其实可以概括为三件事,1. Client向Master打听chunk-server小组中每个机器的地址,以及谁是小组长,2. Client把数据推送给地理距离最近的机器,然后逐步线性扩散到小组中所有机器,3. 小组长决定写入硬盘的顺序后,依次把内存中的数据写入硬盘。

这个工序好不好?好!但是我们今天偏来抬抬杠。抬杠这个词听起来有点情绪化,更贴切的说法是质疑,目的是探究有没有可能进一步改善同步的工序。

1. Client的权力是否过大?

a. Client(如Crawler)知道chunk-server中所有机器的地址,以及当前小组长是谁。这样chunk-server小组的隐私就暴露在client面前。

有人或许会说,反正client是集群内部自己人,不会有恶意攻击的情况发生,所以隐私暴露就暴露吧。这个想法过于乐观了,Google的集群有多达上百万台机器,林子大了什么鸟都有。万一某一台机器被恶意挟持了,或者万一有某个应用程序出了bug,无防范的众多chunk-server就倒霉了。

譬如client方面一个循环语句的中止条件写错,导致client不停地给chunk-server重复地发送相同数据,就像BBS里无聊的人刷屏一样,很快chunk-server的内存将会被灌满。这个时候chunk-server能做什么?要么内存被灌满以后,拒绝随后到达的新数据。如果这样,其它无辜正直的clients就不能顺利地向chunk-server传送数据了。要么,另外一种可能是,chunk-server循环使用内存,新来的数据将覆盖以往的数据。如果发飙的client传送数据的速度很快,那么可能的后果是chunk-server的大部分内存空间,被来自发飙client 的垃圾数据充斥。两种后果都很糟糕。

b. 在关键的第三步,client自主决定先给小组中那一台机器传送数据。Client想什么时候传送数据,就什么时候传送,它不考虑chunk-server的内存是否即将被占满,它也不考虑chunk-server网络带宽是否已经严重堵塞。

在第四步,又是client给小组长下令,把内存里的数据写入硬盘。当小组中各个chunk-server都已经接受到了数据,存放在内存中以后,理应尽快写入硬盘。但是什么时候开始写,决定权又是在这个我行我素的client手中。如果client正在忙着处理其它事情,它就顾不得下令写入硬盘,尽管下这个指令不费吹灰之力。造成的后果是,chunk-server内存中的数据不能及时写入硬盘。内存一旦被占满,后续的数据就不能被顺利发送到 chunk-server,或者先前到达的数据被覆盖。

所以,client掌握了太多的主动权,隐患很多。

c. Client缓存chunk-server中所有机器的地址,以及当前小组长是谁。万一这些信息发生改变,而client没有及时更新,会造成什么后果?

它自说自话地把数据发送给最邻近的chunk-server,进而扩散到小组中其它chunk-servers。然后和自己心目中的小组长联系,说,“所有数据都到位了,您老可以下令让各个chunk-server写进硬盘了”。没想到,小组长回信说,“俺已经卸任了”。得,client只好再找 master,问,“新任小组长是谁啊?”,等等。

如果只是换了一任小组长,那么后果还不算太严重,浪费一点时间而已。如果小组成员中,更换了机器。问题就大了。譬如,client的缓存里说,这个小组有 S1,S2和S3三台chunk-servers,S1和S2都已经回信说传送的数据已经存放在各自的内存中了,可是S3一直没有回音。Client就 re-try,一遍又一遍,无异于灌水。

关于Client缓存过期信息,GFS论文里很坦诚地承认了,这种可能性的确存在,参见第2.7.1节倒数第二段。但是论文辩解说,缓存的时间是有限的,所以这个可能性虽然存在,但是频率不会很高。如果真得束手无策,只能祈求错误出现的频率不高,但是有没有彻底杜绝错误的办法呢?

2. 小组长的权力是否过小?

干部的任命从来就不是一件小事,委任chunk-server小组长也同理。Master在决定谁最适合被任命为小组长时,需要考察小组中所有成员的工作负荷,健康情况等等。虽说这个工作的成本不大,但毕竟是有成本的。更麻烦的在于,委任状是有有效期的,有效期一过,需要注销,或者续约。

审查通过,又续了约,总算稳住了名号,圈里圈外总算有了点人望,却发现却是一个闲职。好生无趣。小组长的职责是什么?无非是第四步时,client递过来个条子,说,“时候差不多了,该把内存里的数据写进硬盘里去了”。小组长便列了个先后次序的单子,让各个chunk-server分头去写。说来说去,稍微有点技术含量的活儿,无非是决定优先顺序。其实也没什么技术含量,多半是重复先来先服务的老把戏。

前面说了,client的权力太大,能不能让闲置的小组长分点权力?皇帝要稳固皇位,无非是在外臣和内戚之间搞平衡。太祖为什么要启用江青和毛远新?无非是外臣势力过大,需要启用内戚来制约而已。

小组长可以做哪些事情?如果GFS让我出主意,我可能会这么建议,

1. 小组长决定哪一个chunk-server去client那里取数据,什么时候去取,而不是由client来决定。

Client没必要,也不应该知道小组中所有chunk-server的地址。由chunk-server主动向client索取要存放的数据,而不允许client随意灌水。

2. 小组长决定chunk-server们什么时候把内存里的数据写进硬盘,而不由clent来决定。

自家内部的事情,岂容外人干涉。

明摆着是夺权。

Client接触的应当是Master和小组长。就像是顾客来到银行,接待他的是大堂经理。顾客对大堂经理说,“我这里有一笔钱想存入贵行”。经理把顾客引到某个柜台,说,“这位服务生负责接待您”。顾客把钱交给服务生,服务生完成所有的储蓄手续。

如果大堂经理递给顾客一张名单,说,“你看,这是我行所有与储蓄业务有关的部门和工作人员,您自主决定怎么存”。估计大多数顾客脸色不会好看。如果某位顾客开怀地笑了,保不定银行将来会失窃。

夺权有理,这个理,并不在于容不下小组长游手好闲,而是在于强调内外有别。

待续

关键词(Tags): #Google#cluster#集群
全看分页树展 · 主题


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河