相关阅读： 云端磁盘：网络巨头如何存储数据（上）
亚马逊S3和Dynamo
当亚马逊开始建立其网络服务平台时，该公司比谷歌有更多不同的应用问题。
直到最近，像GFS一样，Dynamo还没有直接暴露给客户。如同亚马逊首席技术官Werner Vogels在其2007年的博客的解释，它是存储服务和其他高度公开给亚马逊客户的亚马逊云计算服务的基础，包括亚马逊的简单存储服务(S3)和 SimpleDB。但在今年1月18日，亚马逊推出了一个叫做DynamoDB的数据库服务，基于最新改进的Dynamo。它给客户一个如“NoSQL” 数据库的直接接口。
Dynamo与GFS和HDFS有一些相同的地方：它同样是设计成为了高可用性而不关注数据在跨系统交换时的一致性，还为了运行在亚马逊大量集合的硬件上。但是相似性到此为止，因为对Dynamo的要求完全不同。
亚马逊需要一种可以处理更多用途的数据访问的文件系统——比如像是亚马逊自己的电子商务功能，包括顾客购物车，和其他交易型的系统。公司需要更细微和动态的对数据的访问。比起对大数据流的优化，需求更倾向于对稍小元素的更随机的访问，比如类似网页的访问。
根据Vogels和他的团队在2007年10月操作系统原理大会的座谈会上发表的报告，“Dynamo面向那种需要储存相对小的(通常小于1M)目标的应用。”比起为读取的优化，Dynamo更是被设计成“随时可写的”，数据输入高度可用——正好与谷歌的模型相反。
“对于一些亚马逊的服务”，亚马逊Dynamo开发组在报告中写道，“拒绝客户更新可能导致很差的用户体验。例如，购物车服务必须允许顾客从购物车中添加和移除物品即使是在网络和服务器发生故障时。”与此同时，基于Dynamo的服务可以应用到更大的数据集——事实上，亚马逊提供了比Dynamo更好的以S3为基础的基于Hadoop的Elastic MapReduce服务。
为了达到这些要求，Dynamo的架构几乎与GFS有天壤之别——它更接近与一个对等系统而不是主从方式。Dynamo同样逆转了对一致性的处理，去除了让系统在数据写入后解决复制问题，取而代之的是在执行读取数据时解决冲突问题。因此，Dynamo从不拒绝数据写入，不管是新数据还是对现有数据的改动，副本立即更新。
由于担心中央主服务器出错而造成麻烦(根据以往服务中断的经验)和亚马逊为其云服务添加设备的速度，Vogel的团队选择了一种分散的复制方法。它是基于自管理的数据分割方案，使用了一致性哈希的概念。每个Dynamo集群内的资源都被映射成一个连续的环状地址空间，系统中的每个存储节点在被添加到集群中时都被赋予一个随机值——在Dynamo环中表示其“位置”的值。在集群内存储节点数量的基础上，每个节点根据其位置负责地址空间中的一个块。当存储节点被添加到环中时，它们接管了地址空间中的块，环中在它们两侧的节点调整它们所负责的部分。由于亚马逊担心当更新更好的硬件加入集群后存储系统的不平衡负载问题，Dynamo允许将多个虚拟节点分配到每个物理节点上，让集群中的更好的系统更好地分享地址空间。
当数据被写入到Dynamo时——通过一个“put”请求——系统会给要写入的数据分配一个键值。这个值是通过128位MD5哈希得到的;哈希的值 作为数据在环中的一个地址。负责该地址的数据节点会变成该数据的“协调节点”，负责处理对它的请求并把数据复制提交给环中的其他节点。
这将使请求散布到系统中的所有节点。在其中一个节点发生错误时，它在环上的虚拟相邻节点开始接受请求，用它们的副本填补空白。
接下来是Dynamo的一致性检查方案。当一个“get”请求由客户端程序发出时，Dynamo调查它的节点来找到谁有所请求数据的副本。带有副本 的每个节点响应，提供上次改动的信息，基于一个向量时钟——一个追踪数据变化依赖关系的版本控制系统。依照调查的设置，请求处理器可以等待第一个响应并返 回(如果应用程序数据繁忙而且冲突的风险很低——像Hadoop程序一样)或者可以等待两个，三个或者更多响应。对于存储节点的多个响应，处理器进行检查 从而找出哪一个是最新的并提醒陈旧节点从最新的节点处复制数据，或者合并无冲突的编辑的版本。该方案大多数情况下弹性很强——如果节点死了，而新的已经在 线，那么最新的数据将被复制到新节点上。
Dynamo最新的改进，DynamoDB的创立，就是为什么亚马逊内部开发者没有自己采用Dynamo作为他们应用的基础的结果，取而代之的则是，依靠建立在它之上的服务——S3，SimpleDB和Elastic Block Storage。亚马逊在2011年四月中断时所面临的问题就是安装在集群间的副本高于应用套件——在亚马逊Elastic Block Storage，副本超过了可用的额外容量，而不是Dynamo本身的问题。
Dynamo的总体稳定性使它成为开源界模仿者的灵感，就像GFS一样。Facebook依赖于Cassandra，一个基于Dynamo的Apache项目。Basho的Riak “NoSQL”数据库同样来源于Dynamo架构。
微软的Azure DFS
当微软推出Azure平台即服务时，它也面临着一系列类似亚马逊那样的需求——包括大量的多用途存储。但应为它是平台即服务，Azure不会像亚马逊的EC2那样向其客户透露过多内部结构。而且作为一个平台专门建立来服务云客户比为了某个特定任务来建立更有好处。
因此，在一些方面，Azure的存储架构类似于亚马逊的——它的目的是处理各种尺寸的“对象”，表和其他类型的数据，并提供颗粒级的快速访问。替代 了在存储节点自身处理逻辑和物理的数据映射，Azure的存储架构把逻辑和物理数据分区分到了系统的不同层。当传入的数据请求通过一个逻辑地址被分发时， 或“分区”，分布式文件系统自身分解成GB大小的块，或“扩展”。其结果是一种亚马逊和谷歌混合的方法。
如同微软的Brad Calder在他的Azure存储架构概览中描述的那样，Azure使用了一种类似于Dynamo的识别数据位置的验证系统。但不是让应用或服务直接接触 存储节点，请求是通过一个保存数据分区映射的前段层分发的，就类似于HDFS的名字节点。与HDFS不同，Azure使用多个前端服务器，通过它们载入均 衡的请求。前端服务器处理所有的从客户端应用程序的认证请求，并处理与下一层之间的联系——分区层。
每个Azure存储空间的逻辑块都由一个分区服务器管理，它可以追踪哪个DFS区间存储着数据。分区服务器为其特定的存储对象处理读取和写入。这些 对象的物理存储是遍布DFS区间的，因此每个分区服务器都可以访问DFS中的所有区间。除了缓冲前端服务器的读写请求，分区服务器还可以将请求数据缓存在 内存中，因此重复的请求可以在不惊动底层文件系统的情况下得到响应。这将对小的，频繁的请求提高性能，比如呈现一个网页。
每个分区的所有元数据都被复制回一套“分区主”服务器上，如果分区服务器出错会提供信息的备份——如果一台坏了，它的分区会动态传递至其他分区服务器。这些分区主服务区还监视Azure存储集群上每个分区服务器的工作量，分区主服务器可以动态重新分配分区。
Azure不同于其他大型分布式文件系统，它更严格地强调数据写入的一致性。当写入送至DFS时，数据复制开始，但不是GFS和HDFS那种懒散的 复制。每个存储区间都有一个初级的DFS服务器管理并复制到多个二级服务器;一个DFS服务器可以是一个区间子集的初级服务器和其他区间的二级服务器。当 一个分区服务器向DFS送出一个写请求，它将于初级服务器联系获取数据要写入的区间，初级服务器再传递给二级服务器。当数据被三个二级服务器成功复制后， 该次写入才被报告为成功。
与分区层一样，Azure DFS在物理层上使用均衡负载，以防系统被大量输入输出卡死。每个分区服务器都监视着它访问的初级区间服务器的工作量，当初级DFS服务器到警告线时，分区服务器开始将读取请求重新定向至二级服务器，并把写入重新定向至其他服务器的区间上。
“分布式”的下一阶段
分布式文件系统很难保证永久正常运行时间。在大多数情况下，由于保持副本同步所需带宽的数量，DFS只在同一数据中心内复制。但是，在某些情况下， 数据中心内的复制就不管用了，比如说当整个数据中心被迫下线或是当初主服务器出错时，备用网络未能及时切换。在八月，由于变压器爆炸，微软和亚马逊在都柏 林的数据中心都被迫下线——它创造了一个启用备用发电机的峰值。
像GFS和Hadoop这样对复制更缓慢的系统可以在两个数据中心之间异步处理复制;例如，使用“机架感知”，Hadoop集群可设置成指向一个外面的数据节点，元数据可以传送至远程检查点或备份节点(至少在理论上)。但对于更多的动态数据，这种类型的复制将难以管理。
这正是微软在九月发布一个叫做“地域复制”特性的原因之一。地域复制可以将两个相隔数百英里的数据中心的客户数据同步。不是微软在数据中心内使用的紧密耦合复制，地域复制是异步发生的。两个Azure数据中心必须在同一地区;例如，在美国中北部的数据中心通过Azure Portal安装的一个程序的数据可以被复制到美国中南部。
亚马逊的情况是，公司在服务层级上可以在可用区域间复制而不是下行至Dynamo架构。虽然亚马逊没有公布它如何处理自己的地域复制，但是给客户提供了把EBS存储“快照”给一个远程S3数据“桶”的能力。
这就是亚马逊和谷歌在不断发展的分布式文件系统都普遍采取的方法：在以它们为基础的服务上修复调整，而不是在基础架构上。虽然谷歌给GFS添加了一个分布式主系统，并做出了其他调整以适应其日益增长的数据量，但是谷歌系统的基本架构仍像是2003年时的样子。
但长期来看，文件系统本身也许更注重于成为数据的保管处而不是由程序直接接触的东西。在与Ars的一次采访中，数据库先驱(VoltDB的创始人) 迈克尔·斯通布雷克表示，随着“大数据”应用程序数据量的继续上升，服务器内存将成为“新的磁盘”，文件系统将成为储存应用程序活动性日志的地方——“新 的磁带”。当云巨头们在他们的数据中心上推行更高的效率和性能时，他们已经越来越多地朝着固态硬盘和大量系统内存的方向迈进了。
