加载中…闲话Google集群 [4] 数据流和控制流的分离
(2008-09-05 00:07:07)
标签：
cluster集群架构设计杂谈 |
分类： 技术评论 |
[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向这些小组存放 文件时，小组中每一个备份机器都能步调一致地存放这些文件。实际情况远没有那么简单，我们下一节，讲专门谈谈向各个备份小组中存放操作时，如何保持同步的 问题。
上一节，我们讲到了有备份的集群布局。设置备份的动机是增强系统的稳定性。当一部分机器死机了，只要它们的备份机器还在正常运转，哪怕每个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描绘了文件的存放和读取的流程。
https://docs.google.com/File?id=drfcsw8_77ftmcmxch_b[4] 数据流和控制流的分离" TITLE="闲话Google集群 [4] 数据流和控制流的分离" />
这个办法的好处在于，分离了控制流和数据流。
拿 文件存放的流程说事儿，步骤一和步骤二的内容是控制流，它发生在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向这些小组存放 文件时，小组中每一个备份机器都能步调一致地存放这些文件。实际情况远没有那么简单，我们下一节，讲专门谈谈向各个备份小组中存放操作时，如何保持同步的 问题。
喜欢
0
赠金笔