五千年(敝帚自珍)

主题:【原创】闲话Google集群 [4] 数据流和控制流的分 -- 邓侃

共:💬15 🌺46
全看分页树展 · 主题
家园 【原创】闲话Google集群 [4] 数据流和控制流的分

[1] 引子 链接出处

[2] 存在的理由 链接出处

[3] 布局 链接出处

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

上一节,我们讲到了有备份的集群布局。设置备份的动机是增强系统的稳定性。当一部分机器死机了,只要它们的备份机器还在正常运转,哪怕每个Chunk-server备份小组中,各自只有一台机器苟活,整个系统就不至于全面崩溃。

但是一个文件同时存放在多个机器上,引发了同步的难题。所谓同步,就是保证每个备份机器中存放的文件,不仅内容,还有存放位置都必须一模一样。换句话说,每个Chunk-server备份小组中的任何一台机器,都像是小组中其它机器的克隆复制一样。

同步的问题是个难题,尤其难在存放文件的过程中,万一某一个备份机器突然死机了,该怎么办?要解决这个问题,涉及面比较广。我们先谈谈数据流和控制流的分离问题。

我们在上一节的图3-1中,描绘过一个简单的集群布局。这个布局很傻很天真,缺陷之一是无论存放文件还是读取文件,都必须经过Master。当文件数目大,或者文件尺寸大,或者两者兼而有之时,千军万马都必须经过Master这个独木桥,从而Master不可避免地成为瓶颈。我们在图3-2中,对这个布局做了改进,给Master以及每个Chunk-server都增加了备份,但是这个布局的目的是增强系统的稳定性,但是Master group仍然会成为瓶颈。

有没有办法让Crawler以及Reader,绕开Master,直接与Chunk-server发生联系呢?GFS是怎么处理的?

文件存放:

1. 当网络爬虫Crawler想向GFS存放文件时,它首先与GFS的Master联系,问,"嗨,Master,我要存放这样一个文件,它的URL是~~,它的文件尺寸是~~,请告诉我,应该把它存放在哪一个Chunk-server?"

2. Master答复Crawler,"把文件存在这个Chunk-server,它的IP地址和端口是~~"。

3. Crawler与指定的Chunk-server建立起TCP联系。然后把相应文件的数据发给该Chunk-server。

文件读取:

与文件存放的流程类似,Reader先与GFS Master联系,询问文件存放在哪一个Chunk-server。Master告知目标Chunk-server的IP地址和端口。然后Reader直接与目标Chunk-server联系,读取需要的文件。

图4-1描绘了文件的存放和读取的流程。

点看全图

外链图片需谨慎,可能会被源头改

这个办法的好处在于,分离了控制流和数据流。

拿文件存放的流程说事儿,步骤一和步骤二的内容是控制流,它发生在Crawler和Master之间。步骤三是数据流,它发生在Crawler和Chunk-server之间。通常情况下,控制流的数据量很小,而数据流包含的数据量很大,所以在图4-1中,我们用细线表示控制流,而用粗线表示数据流。

虽然每次Crawler要存放文件时,必须首先和Master联络,但是因为它们联络的内容仅仅是小数据量的控制流,所以不至于导致Master成为瓶颈。

这个办法有什么缺点?主要有两条。

1. 大文件的存放和读取效率低下。

设想一下,如果我们有一部很长的电影的视频文件,从头到尾对这个文件进行存放和读取,需要很长时间。

改进的办法是把很长的文件剁成若干小段,分别存放在不同的Chunk-sever groups中去。由于每个Chunk-server group只负责一小段文件,存放和读取都不太耗时。当然,这样的做法会带来一些额外工作,1. 在存放的时候,需要分割源文件。2. 在读取的时候,需要把从不同Chunk-server group读到的文件段落,按顺序拼接起来。GFS就是这么做的,在以后讨论负载平衡的章节中,我们再详谈。

2. 不够安全。

由于Master明白地告诉了Crawler,文件应该存放到哪个Chunk-server,这个目标Chunk-server的IP地址以及端口。日积月累,GFS里面很多Chunk-server的IP地址和端口,都会被Crawler知道。幸亏Crawler是Google系统的一部分,是自己人。否则,就有可能被恶意黑客利用,向Google集群发动攻击。

举个例子,我们任何人都可以使用浏览器来访问Google的地图服务。在我们获取Google地图图片的时候,会发现存放中国各省市地图图片的 Chunk-servers,通常是mt0.google.cn,mt1,mt2,还有mt3。设想一下,如果有谁存心和Google过不去,他可以向这四个Chunk-servers同时发动大量请求,索取地图图片。一时间请求太多,会造成造成mt0到mt4几个Chunk-servers忙不过来。

如果恰好在这个时候,有真正的客户想用Google的地图服务,他就不能正常地在短时间内收到mt[0-4]这些Chunk-servers的反馈,就好像mt[0-4]这些Chunk-server死机了一样。这就是所谓DoS(Donial of Service)攻击。

虽然Google集群规模庞大,黑客不可能对整个Google集群发动DoS攻击,但是却有可能集中力量,攻其一点。只要瘫痪了一个或几个Chunk- server groups,就会造成一部分GFS不能正常读写文件,从而有可能造成一部分Google服务不能正常工作。

有没有办法替Google File System解决安全问题?就笔者的知识所限,目前似乎还没有令人满意的解决办法。这也正是作为技术看客的乐趣所在,知道问题在哪里,听各方辩论解决方案,预测未来的技术走势。这就像股民读经济金融新闻,听各路经济学家分析时局,预测股市未来的走势,然后决定是否要买进或者卖出股票。心惊肉跳的时候到了。玩的不就是心跳吗?

这一节,我们讨论了数据流和控制流的分离。在图4-1中,我们把每个Chunk-server备份小组,当作一个单元。似乎当Crawler向这些小组存放文件时,小组中每一个备份机器都能步调一致地存放这些文件。实际情况远没有那么简单,我们下一节,讲专门谈谈向各个备份小组中存放操作时,如何保持同步的问题。

关键词(Tags): #互联网#Google#集群#操作系统#网络

本帖一共被 2 帖 引用 (帖内工具实现)
全看分页树展 · 主题


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

Copyright © cchere 西西河