云端磁盘:网络巨头如何存储数据(下)
jim 发表于:12年04月09日 09:47 [编译] 存储在线
Azure不同于其他大型分布式文件系统,它更严格地强调数据写入的一致性。当写入送至DFS时,数据复制开始,但不是GFS和HDFS那种懒散的 复制。每个存储区间都有一个初级的DFS服务器管理并复制到多个二级服务器;一个DFS服务器可以是一个区间子集的初级服务器和其他区间的二级服务器。当 一个分区服务器向DFS送出一个写请求,它将于初级服务器联系获取数据要写入的区间,初级服务器再传递给二级服务器。当数据被三个二级服务器成功复制后, 该次写入才被报告为成功。
与分区层一样,Azure DFS在物理层上使用均衡负载,以防系统被大量输入输出卡死。每个分区服务器都监视着它访问的初级区间服务器的工作量,当初级DFS服务器到警告线时,分区服务器开始将读取请求重新定向至二级服务器,并把写入重新定向至其他服务器的区间上。
“分布式”的下一阶段
分布式文件系统很难保证永久正常运行时间。在大多数情况下,由于保持副本同步所需带宽的数量,DFS只在同一数据中心内复制。但是,在某些情况下, 数据中心内的复制就不管用了,比如说当整个数据中心被迫下线或是当初主服务器出错时,备用网络未能及时切换。在八月,由于变压器爆炸,微软和亚马逊在都柏 林的数据中心都被迫下线——它创造了一个启用备用发电机的峰值。
像GFS和Hadoop这样对复制更缓慢的系统可以在两个数据中心之间异步处理复制;例如,使用“机架感知”,Hadoop集群可设置成指向一个外面的数据节点,元数据可以传送至远程检查点或备份节点(至少在理论上)。但对于更多的动态数据,这种类型的复制将难以管理。
这正是微软在九月发布一个叫做“地域复制”特性的原因之一。地域复制可以将两个相隔数百英里的数据中心的客户数据同步。不是微软在数据中心内使用的紧密耦合复制,地域复制是异步发生的。两个Azure数据中心必须在同一地区;例如,在美国中北部的数据中心通过Azure Portal安装的一个程序的数据可以被复制到美国中南部。
亚马逊的情况是,公司在服务层级上可以在可用区域间复制而不是下行至Dynamo架构。虽然亚马逊没有公布它如何处理自己的地域复制,但是给客户提供了把EBS存储“快照”给一个远程S3数据“桶”的能力。
这就是亚马逊和谷歌在不断发展的分布式文件系统都普遍采取的方法:在以它们为基础的服务上修复调整,而不是在基础架构上。虽然谷歌给GFS添加了一个分布式主系统,并做出了其他调整以适应其日益增长的数据量,但是谷歌系统的基本架构仍像是2003年时的样子。
但长期来看,文件系统本身也许更注重于成为数据的保管处而不是由程序直接接触的东西。在与Ars的一次采访中,数据库先驱(VoltDB的创始人) 迈克尔·斯通布雷克表示,随着“大数据”应用程序数据量的继续上升,服务器内存将成为“新的磁盘”,文件系统将成为储存应用程序活动性日志的地方——“新 的磁带”。当云巨头们在他们的数据中心上推行更高的效率和性能时,他们已经越来越多地朝着固态硬盘和大量系统内存的方向迈进了。