五千年(敝帚自珍)

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

共:💬15 🌺46
分页树展主题 · 全看首页 上页
/ 1
下页 末页
  • 家园 【原创】闲话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 帖 引用 (帖内工具实现)
    • 家园 DOS防御和GFS没有关系

      搜索引擎都是按照一定的hash算法存储数据的,也就是说虽然是同样是中国的数据(甚至一个城市的数据)会被hash到不同的机器上。这样做就可以一定程度上避免你说的问题,还有一个好处就是当美国网民查询时候,中国网民在睡觉。

      另外dos防御和GFS没有关系,到了GFS这层都是合法的请求了。在前端dos攻击就应该被过滤掉。

      如果有兴趣,你大可以dos google一把,你会看到要你输入验证码的页面。

      • 家园 负载平衡和安全防御

        也就是说虽然是同样是中国的数据(甚至一个城市的数据)会被hash到不同的机器上。

        同意,在后面讲到负载平衡的时候,会详细说。

        dos防御和GFS没有关系,到了GFS这层都是合法的请求了。在前端dos攻击就应该被过滤掉。

        GFS是不是御敌于国门外,GFS的论文里面没有讲,因为安全问题不是GFS本身架构设计的问题,这个你说的对。

        至于Google集群如何抵御DoS等等攻击,我也不太熟悉。似乎没有公开的文献可以读。不知道谁能详细谈谈,非常有意思的题目。

    • 家园 花送好文

      不知道这两年流行的Megaupload和RapidShare是不是也是采用GFS?

      • 家园 关于MegaUpload和RapidShare

        听说过,但是没有深究,所以不敢在河里乱嚷嚷。

        有哪位爷知情,给大伙儿说几句如何?

    • 家园 先花,再提问。GFS比较适用于海量数据,但是实时性不好

      去年我有一个项目,原来考虑使用gfs,后来放弃了,原因两个

      1、系统运行中产生大量的小数据文件,而且实时性要求很高;hadoop默认的文件块是64m,小了性能不行;大了实时性不能满足要求;

      2、namdenode是一个有状态的单点,无法实时备份。

      后来的解决方法是将中间文件放在存储上,但是硬件成本太高,而且睡着系统的运行,硬盘空间的需求越来越大。

      请教有什么更好的思路么?

      • 家园 关于GFS的实时性

        GFS的实时性的确不是特别好,今后在分析如何分配文件存放方式时会详细解释。

        用GFS存放文件,目的是解决海量规模问题,你的理解正确。用GFS来处理背景操作,如更新Inverted index之类,是很有效的。但是用作Google map线上服务,未必非常合适。

        对于强调实时性的线上服务,最好的办法是把文件缓存在内存里,而不是硬盘中。不过,GFS的论文中没有讲,找遍Google的论文,都没有读到他们是如何解决内存集群的。而我猜测,这才是Google集群最关键的地方。

        等我讲完GFS,以及Bigtable以后,或许会探讨Google Cache Cluster。不过,那已经不是Google论文里的内容,而是我等党外人士,为党献计了。当然,更有可能,党内人士看了后,会冷笑一声,说,“你想到的,我们早就做了。你没想到的,我们也做了。”

        Google的牛人很多,比我等高超不奇怪。先给自己找个体面下台的梯子,呵呵。

        • 家园 最近用memcached做分布式内存cache集群,但是

          还是有缺点,cache key->value形式的小数据比较方便,大一点的文件不好cache。

          顺便说一下,看了看memcached的源码,发现写得还真不错阿,呵呵。

    • 家园 多节点的访问寻径问题在通信领域和并行计算领域

      有大量前人研究的成果。不知怎地,那段网络爬虫和Master的对话让我想起TCP/IP网络设计中的一些想法。

      如果取消Master,那么,可能的一个方法是,每一个节点同时也承担指路的任务,它可能知道,也可能不知道目标节点,但至少知道到达目标节点应该去找谁。同时,请求每经过这样一个节点,就在它发出的客户端或 转发的节点与当前请求到达的节点之间建立起一个连接,直到到达目标节点。在到达目标节点的那一刻,客户端与目标节点之间的“虚电路”也同时宣告建立起来。接下来就是传输了。整个过程就好像虫子在苹果中啃出一条通道一样,因此得名“虫洞理论”。

      这对文中提到的安全性也多少有所补偿。

      好多年没关注了,可能有些记忆错误,也可能早就过时了吧。

      • 家园 去中心化的路由

        有点类似MeshNetwork的做法。

        每个节点保存有限的Routing Table,如果这个节点不知道最终目标,它就把用户介绍给Routing Table中某一个或几个最有可能知道最终目标的节点。

        也有点像Milgram关于六度空间人链传递的试验。链接出处

        但是缺陷是,路由的时间难以控制。

        所以,以小人之心度Googler之腹,GFS的设计者们或许会想,“还是设一个Master方便,更何况Master还有其它用途”。下文中会一一提及Master的其它用途。

分页树展主题 · 全看首页 上页
/ 1
下页 末页


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

Copyright © cchere 西西河