分布式文件系统
分布式文件系统（Distributed FileSystem,DFS）可以提供文件的访问效率，提高文件的可用性并减轻服务器的负担。
分布式文件系统概述
通过分布式文件系统将相同的文件同时存储到网络上多台服务器后，即可拥有以下功能。
●提供文件的访问效率：当客户端通过DFS访问文件时，DFS会引导客户端从最接近
客户端的服务器来访问文件，让客户端快速访问到所需的文件。实际上，DFS是提供客户端一份服务器列表，这些服务器内都有客户端所需要的文件，但是DFS会将最接近客户端的服务器，例如客户端同一个AD DS站点（Active Directory Domain Services Site），放在列表最前面，以便让客户端优先从这台服务器访问文件。
●提高文件的可用性：即使位于服务器列表中最前端的服务器意外发生了故障，客户
端仍然可以从列表中的下一台服务器获取所需的文件，也就是说DFS提供排错功能。
●服务器负载平衡功能：每个客户端获得列表中的服务器排列顺序可能都不相同，因
此他们访问的服务器也可能不相同，也就是说不同客户端可能会从不同服务器来访问所需文件，从而减轻服务器的负担。
DFS的架构
Windows Server 2012是通过文件和访问服务角色内的DFS命名空间与DFS复制这两个服务来配置DFS。下面根据下图来说明DFS中的各个组件。
1.DFS命名空间：可以通过DFS命名空间将位于不同服务器内的共享文件夹集合在一
起，并以一个虚拟文件夹的树状结构呈现给客户端。DFS命名空间分为以下两种。
●域命名空间：它将命名空间的设置数据存储到ADDS与命令空间服务器的内存
缓冲区。如果创建多台命名空间服务器，则它还具备命名空间的排错功能。
从Windows Server 2008开始添加一种称为Windows Server 2008模式的域命名
空间，并将以前旧版的域命名空间称为Windows 2000 S而模式。Windows Server
2008模式域命名空间支持基于访问的枚举（Access-Based Enumeration，ABE，
或翻译为访问型枚举），它根据用户的权限来决定用户是否看到共享文件夹内
的文件与文件夹，也就是说当用户浏览共享文件夹时，他只只能够看到有权限
访问的文件与文件夹。
●独立命名空间：它将命名空间的设置数据存储到命名空间服务器的注册表
（Registry）与内存缓冲区。由于独立命名空间只能够有一台命名空间服务器，因此不具备命名空间的排错功能，除非采用服务器群集。
2.命名空间服务器：用来掌控命名空间（Host Namespace）的服务器。如果是域命名
空间，则这台服务器可以是成员服务器或域控制器，而且你可以设置多台命名空间服务器；如果是独立命名空间，则这台服务器可以是成员服务器，与控制器或独立服务器，不过只能够有一台命名空间服务器。
3.命名空间根目录：它是命名空间的起始点，如上图，此根目录的名称为public，命
名空间的名称为\\https://www.doczj.com/doc/473168402.html,\public,而且它是一个域命名空间，其名称以郁闷开头。
如果这是一个独立命名空间，则命名空间的名称会以计算机名开头，例如
\\server1\public.
由图可知，此命名空间根目录是被映射到命名空间服务器内的一个共享文件夹，默认是%systemDrive%\DFSRoots\Public，它必须位于NTFS磁盘分区。
4.文件夹与文件夹目标：这些虚拟文件夹的目标分别映射到其他服务器内的共享文件
夹。当客户端来浏览文件夹时，DFS会将客户端重定向到文件夹目标所映射的共享文件夹。如图共有3个文件夹，分别说明如下。
●Pictures:此文件夹有两个目标，分别映射到服务器Server2的C:\Pictures与
Server3的C:\Pictures共享文件夹，它具备文件夹的排错功能，例如客户端在读
取文件夹Pictures内的文件时，即使Server2发生故障，它仍然可以从Server3
的C:\Pictures读取文件。当然Server2的C:\Pictures与Server3的C:\Pictures内
存储的文件应该要相同(同步)。
●Database:此文件夹有两个目标，分别映射到服务器Server3的C:\database与
server4的d:\database共享文件夹，它也具备文件夹的排错功能。
●Reports:此文件夹只有一个目标，映射到服务器Server4的D：\Reports共享文
件夹，由于目标只有一个，因此不具备排错功能。
5.DFS复制：图中文件夹Pictures的两个目标映射到的共享文件夹，其中提供给客户
端的文件必须同步，而这个同步操作可由DFS复制服务自动运行。DFS复制服务使用一个称为远程差异压缩的压缩演算技术，它能够检测文件改动的地方，因此复制文件时仅会复制有改动的区域，而不是整个文件，这样可以降低网络的负担。
如果独立命名空间的目标服务器未加入域，则其目标映射到共享文件夹内的文件必须手动同步。
旧版Windows系统通过文件复制服务（File Replication Service，FRS）来负责DFS文件夹的复制与域控制器SYSVOL文件夹的复制。不过，现在只要域功能级别是
Windows Server 2008以上，就会改由DFS复制服务来负责。
复制拓扑
DFS可以选择以下几种拓扑方式来复制文件。
●集散（Huband Spoke）：它将一台服务器当作中枢，并创建与其他所有服务器（支
点）之间的连接。文件是从中枢复制到所有的支点，并且也会从支点复制到中枢。
支点之间并不会直接相互复制文件。
●全交错(Full Mesh)：它会创建所有服务器之间的相互连接，文件会从每个服务器之
间复制到其他所有的服务器。
自定义拓扑：可以自行创建各个服务器之间的逻辑连接关系，也就是自行指定服务器，只有被指定的服务器之间才会复制文件。
可以根据公司网络的带宽，网络的地理位置与公司的组织结构等，决定采用哪种拓扑。无论你选择了哪种拓扑，都可以自行启用或禁用两台服务器之间的连接关系，例如不想让Server2将文件复制到Server3，则可以将Server2到Server3的单向连接关系禁用。
注：上图中的各种拓扑连接关系，并不是硬件上的真正以此形状连接，而是指在复制文件时，利用这些形状描述的逻辑连接关系来复制文件。
DFS的系统需求
独立命名空间服务器可以由域控，成员服务器或独立服务器来扮演，而域命名空间服务器可以由域控或成员服务器来扮演。
参与DFS复制的服务器必须位于同一个ADDS林，被复制的文件夹必须位于NTFS磁盘分区内（ReFS，FAT32与FAT都不支持。）防毒软件必须与DFS兼容，必要时请联系防毒软件厂商以便确认是否兼容。
如果要将域命名空间的模式设置为Windows Server2008模式，则域功能等级必须至少是WindowsServer 2008，另外，所有的域命名空间服务器都必须至少是Windows Server2008.
分布式文件系统实例演示
我们将联系如何来创建一个下图所示的域命名空间，下图三台服务器都是Win Ser 2012 Data.而Server1是域控，Server2和3都是成员服务器，请先创建好此域环境。
图中命名空间的名称，为Public，由于是域命名空间，因此完整的名称将是
\\https://www.doczj.com/doc/473168402.html,\public，它映射到命名空间服务器Server1的C:\DFSRoots\Public文件夹。命名空间的设置数据会被保存到AD DS与命名空间服务器Server1的内存缓冲区。另外，图中还创建了文件夹Picture，他有两个目标，分别指向Server2与Server3的共享文件夹。
安装DFS的相关组件
各个服务器扮演的角色并不完全相同，因此所需安装的服务与功能也有所不同。
●Server1:图中Server1是命名空间服务器，它需要安装DFS命名空间服务(DNS
Namespaceservice)，不过因为这台计算机同时也是域控，而域控默认会自动安装与启用这个服务，因此不需要再手动安装，我们要利用这台服务器来管理DFS，因此需要自行安装DFS管理工具。
●Server2与Server3：这两台目标服务器需要相互复制Pictures共享文件夹内的文件，
因此他们都需要安装DFS复制服务。安装DFS复制服务时，系统会顺便自动安装DFS管理工具，让你可以在Server2和Server3上管理DFS。
在Server1上安装DFS管理工具
添加角色和功能-选择功能-远程服务器管理工具-角色管理工具-文件服务工具-DFS管理工具
在Server2与Server3上安装所需的DFS组件
在Server2和3上安装DFS服务：文件和存储服务-文件和iSCSI服务-DFS复制
在Server2与Server3上创建共享文件夹
在Server2和3上都创建C：\pictures文件夹，并将其设置为共享文件夹，假设共享名都是Pictures，将读取\写入的共享权限赋予Everyone，并且在Server2的pictures内复制一些文件，用于验证这些文件是否确实可以通过DFS机制被自动复制到Server3。
注：真实环境中应该通过适当的权限来确保安全性，此处为实验，所以设置Everyone。
创建新的命名空间
1.在DC1的DFS管理页面中单击命名空间右侧的新建命名空间。
2.选择DC1当作命名空间服务器
3.设置命名空间名称（例如Public）
注：系统默认会在命名空间服务器的%systemdrive%磁盘内创建DFSRoots\Public
共享文件夹，共享名为Public，所有用户都有只读权限，如果要更改设置，可以单击编辑设置。
4.选择域命名空间，默认会选择Windows Server 2008模式。由于域名为https://www.doczj.com/doc/473168402.html,，
因此网站的命名空间名将是\\https://www.doczj.com/doc/473168402.html,\public。
5.检查设置无误有单击创建
6.完成后的界面
创建文件夹
创建下图所示的DFS文件夹Pictures，其两个目标分别映射到\\server2\pictures与\\server3\pictures。
创建文件夹Pictures，并将目标映射到\\Server2\Pictures
1.单击新建文件夹
2.设置文件夹名称，点击添加输入文件夹目标的路径。
客户端可以通过背景图中的预览命名空间的路径来访问映射共享文件夹内的文件。
添加另一个目标，并将其映射到\\Server4\Pictures
1.继续单击添加来设置文件夹的新目标路径
2.选择否，下后门复制组与复制设置不买在说明两个目标之间的复制设置
3.下图为完成后的界面
文件夹Pictures的目标同时映射到\\Server2\Pictures与Server3共享文件夹。以后如果需要增加目标，可以单击右侧的添加文件夹目标。
复制组与复制设置
如果一个DFS文件夹有多个目标，这些目标映射的共享文件夹内的文件必须同步。我们可以让这些目标之间自动复制文件来同步。不过，需要将这些目标服务器设置为同一个复制组，并作适当的设置。
1.单击文件夹Pictures右侧的复制文件夹
2.单击下一步，采用默认的复制组名称和文件夹名称(或自行设置名称)。
3.下面会列出有资格参与复制的服务器
4.选择主要成员(例如Server2)，当DFS第一次开始执行复制文件的操作时，会将这台
主要成员内的文件复制到其他所有目标。
注：只有在第一次执行复制工作时，DFS才会将主要成员的文件复制到其他的目标，之后的复制工作按照所选的复制拓扑进行复制。
5.选择复制拓扑后单击完成（必须有3台及以上的服务器参与复制，才可以选择集散
拓扑）。
6.可以选择全天候，使用完整的带宽进行复制。也可以通过在指定日期和时间内复制
进一步设置
7.确认设置无误后单击创建
8.单击确定
此对话框在提醒你，如果域内有多台域控制器，则以上设置需要等一段时间才会被复制到其他域控制器，而其他参与复制的服务器，也需要一段时间才会向域控制器索取这些设置值。总而言之，参与复制的服务器需要一段时间才会开始执行复制的工作。
9.由于我们的Server2为主要成员，因此稍后当DFS第一次执行复制操作时，会将
\\Server2\Pictures内的文件复制到\\Server3\Pictures。下图是Server3已经复制完成。
注：在第一次复制时，系统会将原本就存在于\\Server3\Pictures内的文件，移动到上图中的文件夹DfsPrivate\PreExisting内，不过因为DfsrPrivate是隐藏文件夹，因此如果要看到此文件夹需要显示隐藏的文件。
从第二次开始的复制操作，将按照复制拓扑来决定复制的方式，例如，如果复制拓扑被设置为交错，则当你将一个文件复制到任何一台服务器的共享文件夹后，DFS复制服务会将这个文件复制到其他所有的服务器。
复制拓扑与计划设置
如果要修改复制设置，可以通过右侧的操作窗格来更改复制设置，例如增加参与复制的服务器，添加复制文件夹，创建服务器之间的复制连接，更改复制拓扑，创建诊断报告等。
无论复制拓扑是什么，都可以自行启用或禁用两台服务器之间的连接关系，例如，如果不想让Server3将文件复制到Server2，请将Server3到Server2的单向连接关系禁用：单击链接-双击发送成员Server3-取消勾选在此连接上启用复制。
还可以通过双击下图已复制文件夹下的Pictures的方式来筛选文件或子文件夹，被筛选的文件或子文件夹将不会被复制。筛选时可以使用通配符？或*，例如*.tmp表示排除所有扩展名为.tmp的文件。
从客户端测试DFS功能是否正常
我们利用win8客户端来说明如何访问DFS文件。计算机先映射网络驱动器。
注：如果要访问独立DFS，请将域名改成计算机名，例如\\server5\public\pictures。
如何知道访问到的文件是位于Server2还是Server3的，可以在Server2和3内分别打开计算机管理查看你的用户与计算机名显示在哪台上。
得知连接的服务器后，请将这台服务器关机，然后到Win8计算机上来访问Pictures内的文件，会发现还可以访问到Pictures内的文件，因为DFS已经重定向到另一台服务器（会稍有延迟）。
６苏州大学学报（工科版）第３０卷 图１Ｉ－ＩＤＦＳ架构 ２ＨＤＦＳ与ＬｉｎｕｘＦＳ比较 ＨＤＦＳ的节点不管是ＤａｔａＮｏｄｅ还是ＮａｍｅＮｏｄｅ都运行在Ｌｉｎｕｘ上，ＨＤＦＳ的每次读／写操作都要通过ＬｉｎｕｘＦＳ的读／写操作来完成，从这个角度来看，ＬｉｎｕｘＰＳ是ＨＤＦＳ的底层文件系统。 ２．１目录树（ＤｉｒｅｃｔｏｒｙＴｒｅｅ） 两种文件系统都选择“树”来组织文件，我们称之为目录树。文件存储在“树叶”，其余的节点都是目录。但两者细节结构存在区别，如图２与图３所示。 一二 Ｒｏｏｔ ＼ 图２ＩｔＤＦＳ目录树围３ＬｉｎｕｘＦＳ目录树 ２．２数据块（Ｂｌｏｃｋ） Ｂｌｏｃｋ是ＬｉｎｕｘＦＳ读／写操作的最小单元，大小相等。典型的ＬｉｎｕｘＦＳＢｌｏｃｋ大小为４ＭＢ，Ｂｌｏｃｋ与ＤａｔａＮ－ｏｄｅ之间的对应关系是固定的、天然存在的，不需要系统定义。 ＨＤＦＳ读／写操作的最小单元也称为Ｂｌｏｃｋ，大小可以由用户定义，默认值是６４ＭＢ。Ｂｌｏｃｋ与ＤａｔａＮｏｄｅ的对应关系是动态的，需要系统进行描述、管理。整个集群来看，每个Ｂｌｏｃｋ存在至少三个内容一样的备份，且一定存放在不同的计算机上。 ２．３索引节点（ＩＮｏｄｅ） ＬｉｎｕｘＦＳ中的每个文件及目录都由一个ＩＮｏｄｅ代表，ＩＮｏｄｅ中定义一组外存上的Ｂｌｏｃｋ。 ＨＤＰＳ中ＩＮｏｄｅ是目录树的单元，ＨＤＦＳ的目录树正是在ＩＮｏｄｅ的集合之上生成的。ＩＮｏｄｅ分为两类，一类ＩＮｏｄｅ代表文件，指向一组Ｂｌｏｃｋ，没有子ＩＮｏｄｅ，是目录树的叶节点；另一类ＩＮｏｄｅ代表目录，没有Ｂｌｏｃｋ，指向一组子ＩＮｏｄｅ，作为索引节点。在Ｈａｄｏｏｐ０．１６．０之前，只有一类ＩＮｏｄｅ，每个ＩＮｏｄｅ都指向Ｂｌｏｃｋ和子ＩＮ－ｏｄｅ，比现有的ＩＮｏｄｅ占用更多的内存空间。 ２．４目录项（Ｄｅｎｔｒｙ） Ｄｅｎｔｒｙ是ＬｉｎｕｘＦＳ的核心数据结构，通过指向父Ｄｅｎ姆和子Ｄｅｎｔｒｙ生成目录树，同时也记录了文件名并 指向ＩＮｏｄｅ，事实上是建立了＜ＦｉｌｅＮａｍｅ，ＩＮｏｄｅ＞，目录树中同一个ＩＮｏｄｅ可以有多个这样的映射，这正是连
分布式存储系统的一些理解和实践 张建伟 一、分布式存储系统介绍 1.简介 互联网数据规模越来越大，并发请求越来越高，传统的关系数据库，在很多使用场景下并不能很好的满足需求。分布式存储系统应运而生。它有良好的扩展性，弱化关系数据模型，甚至弱化一致性要求，以得到高并发和高性能。按功能分类，主要有以下几种： ?分布式文件系统 hdfs ceph glusterfs tfs ?分布式对象存储 s3(dynamo) ceph bcs(mola) ?分布式表格存储 hbase cassandra oceanbase ?块存储 ceph ebs(amazon) 分布式存储系统，包括分布式系统和单机存储两部分；不同的系统，虽在功能支持、实现机制、实现语言等方面是有差异的，但其设计时，关注的关键问题是基本相同的。单机存储的主流实现方式，有hash引擎、B+树引擎和LSM树(Log Structured Merge Tree)三种，不展开介绍。本文第二章节，主要结合hbase、cassandra和ceph，讲下分布式系统设计部分，需要关注的关键问题。 2.适用场景 各分布式存储系统功能定位不尽相同，但其适用和不适用的场景，在一定程度上是相同的，如下。
1)适用 大数据量（大于100T，乃至几十PB） key/value或者半结构化数据 高吞吐 高性能 高扩展 2)不适用 Sql查询 复杂查询，如联表查询 复杂事务 二、分布式存储系统设计要点 1.数据分布 分布式存储，可以由成千甚至上万台机器组成，以实现海量数据存储和高并发。那它最先要解决的就是数据分布问题，即哪些数据存储在哪些机器（节点）上。常用的有hash类算法和用meta表映射两种方式。一般完全分布式的设计（无master节点），会用hash类算法；而集中式的设计（有master节点）用meta表映射的方式。两者各有优缺点，后面讲到具体问题时再做比较。 1)一致性hash 将存储节点和操作的key（key唯一标识存储的object，有时也叫object name）都hash到0~2的32次方区间。映射到如下环中的某个位置。沿操作key的位置顺时针找到的第一个节点即为此key的primary存储节点。如下图所示：
HDFS分布式文件系统具备的优点 随着互联网数据规模的不断增大，对文件存储系统提出了更高的要求，需要更大的容量、更好的性能以及更高安全性的文件存储系统，与传统分布式文件系统一样，HDFS分布式文件系统也是通过计算机网络与节点相连，但也有优于传统分布式文件系统的优点。 1. 支持超大文件 HDFS分布式文件系统具有很大的数据集，可以存储TB或PB级别的超大数据文件，能够提供比较高的数据传输带宽与数据访问吞吐量，相应的，HDFS开放了一些POSIX的必须接口，容许流式访问文件系统的数据。 2. 高容错性能 HDFS面向的是成百上千的服务器集群，每台服务器上存储着文件系统的部分数据，在集群的环境中，硬件故障是常见的问题，这就意味着总是有一部分硬件因各种原因而无法工作，因此，错误检测和快速、自动的恢复是HDFS最核心的架构目标，因此，HDFS具有高度的容错性。 3. 高数据吞吐量 HDFS采用的是“一次性写，多次读”这种简单的数据一致性模型，在HDFS 中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了，这样简单的一致性模型，有利于提高吞吐量。 4. 流式数据访问 HDFS的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理，应用程序能以流的形式访问数据
集。 Hadoop已经迅速成长为首选的、适用于非结构化数据的大数据分析解决方案，HDFS分布式文件系统是Hadoop的核心组件之一，保证了大数据的可靠存储，与MapReduce配合使用，可以对结构化和复杂大数据进行快速、可靠分析，从而为企业做出更好的决策，促进收入增长，改善服务，降低成本提供有力支撑！
Hadoop分布式文件系统：架构和设计 引言 (2) 一前提和设计目标 (2) 1 hadoop和云计算的关系 (2) 2 流式数据访问 (2) 3 大规模数据集 (2) 4 简单的一致性模型 (3) 5 异构软硬件平台间的可移植性 (3) 6 硬件错误 (3) 二HDFS重要名词解释 (3) 1 Namenode (4) 2 secondary Namenode (5) 3 Datanode (6) 4 jobTracker (6) 5 TaskTracker (6) 三HDFS数据存储 (7) 1 HDFS数据存储特点 (7) 2 心跳机制 (7) 3 副本存放 (7) 4 副本选择 (7) 5 安全模式 (8) 四HDFS数据健壮性 (8) 1 磁盘数据错误，心跳检测和重新复制 (8) 2 集群均衡 (8) 3 数据完整性 (8) 4 元数据磁盘错误 (8) 5 快照 (9)
引言 云计算（cloud computing)，由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。在此过程中被服务者只是提供需求并获取服务结果，对于需求被服务的过程并不知情。同时服务者以最优利用的方式动态地把资源分配给众多的服务请求者，以求达到最大效益。 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS 能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。 一前提和设计目标 1 hadoop和云计算的关系 云计算由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。针对海量文本数据处理,为实现快速文本处理响应,缩短海量数据为辅助决策提供服务的时间,基于Hadoop云计算平台,建立HDFS分布式文件系统存储海量文本数据集,通过文本词频利用MapReduce原理建立分布式索引,以分布式数据库HBase 存储关键词索引,并提供实时检索,实现对海量文本数据的分布式并行处理.实验结果表 明,Hadoop框架为大规模数据的分布式并行处理提供了很好的解决方案。 2 流式数据访问 运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3 大规模数据集 运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
DFS使用方法总结（超详细） 使用分布式文件系统 (DFS)，系统管理员可以使用户方便地访问和管理物理上分布在网络各处的文件。通过DFS，可以使分布在多个服务器上的文件如同位于网络上的一个位置一样显示在用户面前。 您可采用两种方式实施分布式文件系统：一种是独立的根目录分布式文件系统，另一种是域分布式文件系统。 独立的DFS根目录： 不使用 Active Directory。 至多只能有一个根目录级别的目标。 使用文件复制服务不能支持自动文件复制。 通过服务器群集支持容错。 域DFS根目录： 必须宿主在域成员服务器上。 使它的DFS名称空间自动发布到 Active Directory 中。 可以有多个根目录级别的目标。 通过 FRS 支持自动文件复制。 通过 FRS 支持容错。 分布式文件系统 (DFS) 映射由一个DFS根目录、一个或多个DFS链接以及指向一个或多个目标的引用组成。 DFS根目录所驻留的域服务器称为主服务器。通过在域中的其他服务器上创建根目标，可以复制DFS根目录。这将确保在主服务器不可用时，文件仍可使用。因为域分布式文件系统的主服务器是域中的成员服务器，所以默认情况下，DFS映射将自动发布到 Active Directory 中，从而提供了跨越主服务器的DFS拓扑同步。这反过来又对DFS根目录提供了容错性，并支持目标的可选复制。通过向DFS根目录中添加DFS链接，您可扩展DFS映射。Windows Server 2003 家族对DFS映射中分层结构的层数的唯一限制是对任何文件路径最多使用 260 个字符。新DFS链接可以引用具有或没有子文件夹的目标，或引用整个Windows Server 2003 家族卷。 创建DFS根目录 使用DFS管理工具，您可以指定某个目标，指派它为DFS根目录。除了访问该目标外，用户还可以访问该目标的任何子文件夹。使用 Windows Server 2003 Enterprise Edition 或Windows Server 2003 Datacenter Edition 时，您可在单独计算机上作为多个DFS根目录的宿主。由于DFS Active Directory 对象的大小，大型的基于域的DFS名称空间可能会显著地增加网络传输量。因此，建议您为域根使用的DFS链接的个数少于 5000。建议在运行 Windows Server 2003 的服务器上的独立的根目录的最大名称空间为 50,000 个链接。 如何创建DFS根目录: 1.打开分布式文件系统。 2.在“操作”菜单上，单击“新建根目录”。
第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块： a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇：用于存储所有的数据和元数据。 c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和 目录名） 1.3 架构原理 Client：用户 I/O：输入/输出 MDS：Metadata Cluster Server 元数据簇服务器 OSD：Object Storage Device 对象存储设备
Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式： 1. 直接通过Client实例连接到Client； 2. 通过一个文件系统连接到Client。 当一个进行打开一个文件时，Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权（如果该Client还没有的话）。目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client 都允许）。之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。 CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH（著名的映射函数）分配给OSD。例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的，如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client 关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。它重新定义了那些存在的并包含文件数据的对象的集合。 CEPH的设计思想有一些创新点主要有以下两个方面： 第一，数据的定位是通过CRUSH算法来实现的。
分布式文件系统（DFS）解决方案 一“分布式文件系统（DFS）”概述 DFS并不是一种文件系统，它是Windows Server System上的一种客户/服务器模式的网络服务。它可以让把局域网中不同计算机上的不同的文件共享按照其功能组织成一个逻辑的分级目录结构。系统管理员可以利用分布式文件系统(DFS)，使用户访问和管理那些物理上跨网络分布的文件更加容易。通过DFS，可以使分布在多个服务器或者不同网络位置的文件在用户面前显示时，就如同位于网络上的一个位置。用户在访问文件时不再需要知道和指定它们的实际物理位置。 例如，如果您的销售资料分散在某个域中的多个存储设备上，您可以利用DFS 使其显示时就好像所有的资料都位于同一网络共享下，这样用户就不必到网络上的多个位置去查找他们需要的信息。 二部署使用“分布式文件系统（DFS）”的原因 ●访问共享文件夹的用户分布在一个站点的多个位置或多个站点上； ●大多数用户都需要访问多个共享文件夹； ●通过重新分布共享文件夹可以改善服务器的负载平衡状况； ●用户需要对共享文件夹的不间断访问；
●您的组织中有供内部或外部使用的Web 站点； ●用户访问共享文件需要权限。 三“分布式文件系统（DFS）”类型 可以按下面两种方式中的任何一种来实施分布式文件系统： 1．作为独立的分布式文件系统。 ●不使用Active Directory。 ●至多只能有一个根目录级别的目标。 ●使用文件复制服务不能支持自动文件复制。 ●通过服务器群集支持容错。 2．作为基于域的分布式文件系统。 ●必须宿主在域成员服务器上。 ●使它的DFS 名称空间自动发布到Active Directory 中。 ●可以有多个根目录级别的目标。 ●通过FRS 支持自动文件复制。 ●通过FRS 支持容错。 四分布式文件系统特性 除了Windows Server System 中基于服务器的DFS 组件外，还有基于客户的DFS 组件。DFS 客户程序可以将对DFS 根目录或DFS 链接的引用缓存一段时间，该时间由管理员指定。此存储和读取过程对于
FastDFS (7) Fastdfs简介 (7) Fastdfs系统结构图 (7) FastDFS和mogileFS的对比 (8) MogileFS (10) Mogilefs简介 (10) Mogilefs组成部分 (10) 0）数据库（MySQL）部分 (10) 1）存储节点 (11) 2）trackers（跟踪器） (11) 3）工具 (11) 4）Client (11) Mogilefs的特点 (12) 1. 应用层——没有特殊的组件要求 (12) 2. 无单点失败 (12) 3. 自动的文件复制 (12) 4. “比RAID好多了” (12) 5. 传输中立，无特殊协议 (13) 6.简单的命名空间 (13) 7.不用共享任何东西 (13) 8.不需要RAID (13)
9.不会碰到文件系统本身的不可知情况 (13) HDFS (14) HDFS简介 (14) 特点和目标 (14) 1. 硬件故障 (14) 2. 流式的数据访问 (14) 3. 简单一致性模型 (15) 4. 通信协议 (15) 基本概念 (15) 1. 数据块(block) (15) 2. 元数据节点(Namenode)和数据节点(datanode) . 16 2.1这些结点的用途 (16) 2.2元数据节点文件夹结构 (17) 2.3文件系统命名空间映像文件及修改日志 (18) 2.4从元数据节点的目录结构 (21) 2.5数据节点的目录结构 (21) 文件读写 (22) 1.读取文件 (22) 1.1 读取文件示意图 (22) 1.2 文件读取的过程 (23) 2.写入文件 (24) 2.1 写入文件示意图 (24)
分布式文件系统概述（一） 杨栋 yangdonglee@https://www.doczj.com/doc/473168402.html, 2006-12 摘要 文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。随着网络的兴起，为了解决资源共享问题，出现了分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。本文1简要回顾了本地文件系统，然后按照发展例程大致介绍了2006年之前各时期主要的分布式文件系统，最后从设计目标、体系结构及关键技术等方面比较了各个分布式文件系统的异同。目前很火的Hadoop文件系统、S3文件系统都是从NFS等早期文件系统一步步演化而来的，了解分布式文件系统的历史，有助于大家更加深刻地领会分布式文件系统的精髓。 1本文写于2006年底，借鉴了别人的大量资料，目的是为了与同学们分享分布式文件系统的发展史。笔者在硕士期间跟随中科院计算所的孟老师、熊老师和唐荣锋进行分布式文件系统的研究和开发。分布式文件系统源远流长，本文只是选择了其发展史上的部分实例进行简单描述，由于笔者水平十分有限，错误之处难免很多，各位同学发现问题之后麻烦回复邮件到yangdonglee@https://www.doczj.com/doc/473168402.html,，我会尽全力完善，或者请各位同学自行修正。笔者目前在百度进行云计算方面的研究和开发，希望有兴趣的同学一起进行探讨。
目录 1．引言 (5) 2．本地文件系统 (5) 2.1FFS (6) 2.2LFS (6) 2.3Ext3 (7) 3．分布式文件系统 (7) 3.1 发展历程 (7) 3.2分布式文件系统分类 (8) 3.2.1 实现方法 (8) 3.2.2研究状况 (8) 3.3 NFS (9) 3.3.1概述 (9) 3.3.2 体系结构 (9) 3.3.3 通信机制 (10) 3.3.4进程 (10) 3.3.5 命名 (10) 3.3.6 同步机制 (11) 3.3.7 缓存和复制 (11) 3.3.8 容错性 (12) 3.3.9 安全性 (13) 3.4 AFS、DFS、Coda和InterMezzo (13) 3.5 SpriteFS和Zebra (14) 3.6xFS (16) 3.6.1 概述 (16) 3.6.2 体系结构 (16) 3.6.3 通信 (16) 3.6.4 进程 (17) 3.6.5 命名 (18) 3.6.6 缓存 (19)
常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。 Google学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable（大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版(Bigtable、 GFS、 Google MapReduce)就有了。做个中文版下载源：https://www.doczj.com/doc/473168402.html,/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： https://www.doczj.com/doc/473168402.html,/papers/gfs.html https://www.doczj.com/doc/473168402.html,/papers/bigtable.html https://www.doczj.com/doc/473168402.html,/papers/mapreduce.html GFS（Google File System） -------------------------------------- Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类 GFS的产品。
分布式文件系统、集群文件系统、并行文件系统，这三种概念很容易混淆，实际中大家也经常不加区分地使用。总是有人问起这三者的区别和联系，其实它们之间在概念上的确有交叉重叠的地方，但是也存在显著不同之处。分布式文件系统自然地，分布式是重点，它是相对与本地文件系统而言的。分布式文件系统通常指C/S架构或网络文件系统，用户数据没有直接连接到本地主机，而是存储在远程存储服务器上。NFS/CIFS是最为常见的分布式文件系统，这就是我们说的NAS系统。分布式文件系统中，存储服务器的节点数可能是1个(如传统NAS)，也可以有多个(如集群NAS)。对于单个节点的分布式文件系统来说，存在单点故障和性能瓶颈问题。除了NAS以外，典型的分布式文件系统还有AFS，以及下面将要介绍的集群文件系统(如Lustre, GlusterFS, PVFS2等)。集群文件系统集群主要分为高性能集群HPC(High Performance Cluster)、高可用集群HAC(High Availablity Cluster)和负载均衡集群LBC(Load Balancing Cluster)。集群文件系统是指协同多个节点提供高性能、高可用或负载均衡的文件系统，它是分布式文件系统的一个子集，消除了单点故障和性能瓶问题。对于客户端来说集群是透明的，它看到是一个单一的全局命名空间，用户文件访问请求被分散到所有集群上进行处理。此外，可扩展性(包括Scale-Up和Scale-Out)、可靠性、易管理等也是集群文件系统追求的目标。在元数据管理方面，可以采用专用的服务器，也可以采用服务器集群，或者采用完全对等分布的无专用元数据服务器架构。目前典型的集群文件系统有SONAS, ISILON, IBRIX, NetAPP-GX, Lustre, PVFS2, GlusterFS, Google File System, LoongStore, CZSS等。并行文件系统这种文件系统能够支持并行应用，比如MPI。在并行文件系统环境下，所有客户端可以在同一时间并发读写同一个文件。并发读，大部分文件系统都能够实现。并发写实现起来要复杂许多，既要保证数据一致性，又要最大限度提高并行性，因此在锁机制方面需要特别设计，如细粒度的字节锁。通常SAN 共享文件系统都是并行文件系统，如GPFS、StorNext、GFS、BWFS，集群文件系统大多也是并行文件系统，如Lustre, Panasas等。如何区分？区分这三者的重点是分布式、集群、并行三个前缀关键字。简单来说，非本地直连的、通过网络连接的，这种为分布式文件系统；分布式文件系统中，服务器节点由多个组成的，这种为集群文件系统；支持并行应用(如MPI)的，这种为并行文件系统。在上面所举的例子中也可以看出，这三个概念之间具有重叠之处，比如Lustre，它既是分布式文件系统，也是集群和并行文件系统。但是，它们也有不同之处。集群文件系统是分布式文件系统，但反之则不成立，比如NAS、AFS。SAN文件系统是并行文件系统，但可能不是集群文件系统，如StorNext。GFS、HDFS之类，它们是集群文件系统，但可能不是并行文件系统。实际中，三者概念搞理清后，分析清楚文件系统的特征，应该还是容易正确地为其划分类别的。
明确要求采用分布式架构存储，而非传统集中式存储FCSAN/IP SAN的原因：从软件定义存储概念提出到现在，分布式架构存储系统正成为业界存储主流和发展方向，逐渐取代传统集中式存储系统，随着云计算和大数据的建设成为数据中心建设主流形态，互联网+、人工智能、物联网应用等的普及，以非结构化数据为主的海量数据爆发式增长，如视音频存储、图像存储及识别、流媒体处理等，基于海量数据存储、分析、挖掘等，传统集中式存储无论从架构、扩展性、性能及成本，运维管理优势等方面，都无法满足业务增长及数据处理所带来的存储问题。 首先从架构上，集中式存储FC SAN/IP SAN 采用Scale up的扩展方式，通过存储控制器挂接扩展柜的方式，实现存储容量的扩展，扩展能力有限，并且性能随着容量扩展并非线性关系，可能存储前端及后端端口带宽会成为海量数据并发处理的瓶颈，并且存储资源分布不均，无法做到资源动态均衡伸缩及调度，这对于响应级别要求不一致的应用来说是致命的；分布式架构存储系统，采用Scale out 横向扩展方式，无节点扩展限制，存储容量可轻易扩展至几十甚至几百PB以上，这是集中式存储无法做到的，能够很好解决在云计算架构下海量数据存储及并发问题。并且基于分布式软件的分布式调度算法，可实现资源动态伸缩，随着节点增加，其性能是线性增加，能够很好满足如云计算架构下海量数据存储及处理对存储资源池可动态伸缩及并发访问性能要求。 由于采用软件定义存储方式，无论是成本还是后期运维管理，比传统集中式存储FC SAN/ IP SAN优势明显，分布式软件自动实现对存储资源调度及管理，实现跨数据中心资源分配。集中式存储系统，需要借助存储虚拟化技术（虚拟化网关）才能将存储资源聚合为统一存储资源池，随着规模扩大，网关往往更易成为性能瓶颈。 关于数据安全性问题，分布式架构存储系统基于机架自动感知的数据多副本技术，例如采用三副本技术，即使数据中心同一机架故障，对业务透明无感知，数据安全级别高，业务连续性更好。集中式存储往往采用双活架构实现容灾，不仅初期投入成本高，运维部署复杂。 从应用角度来看，现在越来越多的应用迁到分布式存储系统上，例如海量视频、音频、图像、文档的存储，流媒体及视频图像处理所带来的高并发低延迟，高性能计算应用等，都非常适合分布式架构存储系统，而不采用集中式存储系统，并且从数据存储及性能要求、容量扩展方便，集中式存储做起来非常困难。 诸如以上原因，明确要求采用采用分布式架构存储，而非传统集中式存储FCSAN/IP SAN。
文件系统比较 MogileFS MogileFS是一款开源的、高性能的、分布式的文件系统，用于组建分布式文件集群，跟Memcached是同门，都由LiveJournal旗下Danga Interactive公司开发。 MogileFS能干什么 最主要的功能就是：用来存取海量文件，而不用关心具体的文件存放位置、存储容量大小，以及文件损坏和丢失等问题。 MogileFS特点 1：应用层：不需要特殊的核心组件 2：无单点失败：MogileFS分布式文件存储系统安装的三个组件（存储节点、跟踪器、跟踪用的数据库），均可运行在多个机器上，因此没有单点失败。 3：自动进行文件复制：基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。 4：比RAID更好：在一个非存储区域网络的RAID中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。MogileFS分布式文件存储系统在不同的机器之间进行文件复制，因此文件始终是可用的。 5：传输中立，无特殊协议 6：简单的命名空间：文件通过一个给定的key来确定，是一个全局的命名空间 MogileFS的适用性——擅长处理海量小文件 由于MogileFS不支持对一个文件的随机读写，因此注定了只适合做一部分 应用。比如图片服务，静态HTML服务。 FastDFS FastDFS是一个开源的分布式文件系统，她对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
分布式文件系统研究16：Global File System 分类：技术日志 前段时间比较忙，好久没发技术文章了，几天来一个，嘿嘿 Global File System 简介 GFS（Global File System）是Minnesota大学开发的基于SAN的共享存储的机群文件系统，后来Sis tina公司将GFS产品化。GFS在很长一段时间都是以源代码开放软件的形式出现的，后来由于Sistina希望通过向用户提供支持和服务的计划未能取得成功，为了要促进自己的财务收入，Sistina在2001年将GFS 变成了一种“专有软件”。Red Hat公司收购Sistina之后，在遵循GPL协议（General Public License）的条件下履行诺言公开了GFS的源代码。现在，GFS的全名被称为“红帽全球文件系统”（Red Hat Global File System ，GFS）的软件，每台服务器每年收取2200美元的费用。 可能是redhat为了更好的收取服务费的缘故，有关GFS的文档真是少之又少，我只能从网上一些零星的资料来看看GFS的概貌。 框架 GFS最初是在IRIX上开发的，后来移植到LINUX上，并开放源码。基本框架如下图所示。 图1 GFS的基本框架图 通过使用GFS，多台服务器可以共用一个文件系统来存储文件。信息既可以存储在服务器上，也可以存储在一个存储局域网络上。 GFS与GPFS结构相似，但它是全对称的机群文件系统，没有服务器，因而没有性能瓶颈和单一故障点。GFS将文件数据缓存于节点的存储设备中，而不是缓存在节点的内存中。并通过设备锁来同步不同节点对文件的访问，保持UNIX文件共享语义。GFS实现了日志，节点失效可以快速恢复。GFS使用SCSI
3种分布式文件系统
第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块： a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇：用于存储所有的数据和元数据。 c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和 目录名） 1.3 架构原理 Client：用户 I/O：输入/输出 MDS：Metadata Cluster Server 元数据簇服务器 OSD：Object Storage Device 对象存储设备
传统的，或者通常的并行文件系统，数据的定位的信息是保存在文件的metadata 中的，也就是inode结构中，通过到metadata server上去获取数据分布的信息。而在Ceph中，是通过CRUSH 这个算法来提供数据定位的。 第二，元数据服务器可以提供集群metadata server 服务。 只要当我们了解了其结构后，感觉并没有太大的特点。元数据服务器一般就用来存储文件和目录的信息，提供统一的命名服务。在Ceph中，元数据的inode ， dentry，以及日志都是在对象存储集群RADOS中存储，这就使得metadata的持久化都是在远程的RADOS中完成，metadata server 不保存状态，只是缓存最近的inode 和 dentry项，当metadata server 失效后，其所所有信息都可以从RADOS中获取，可以比较容易恢复。 CEPH最核心的，就是RADOS就是RADOS（resilient automatic distributed object storage). 其resilient 指的是可以轻松扩展，automatic 指的是其对象存储集群可以处理failover， failure recovery。RADOS 对象集群其对外提供了一个高可用的，可扩展的，对象集群，从客户端的角度看，就是一个统一命名空间的对象存储。 1.4 使用方式 (一)Ceph 的Monitor 用来监控集群中所有节点的状态信息，完成类似配置服务的功能。在Ceph 里，配置主要就是cluster map ，其保存集群所有节点信息，并和所有的节点保持心跳，来监控所有的节点状态。 其通过Paxos算法实现实现自身的高可用，也就是说，这个Ceph Monitor 是不会有单点问题的。目前流行的zookeeper 的功能，以及实现都类似。(二)对象存储 Ceph文件系统中的数据和元数据都保存在对象中。对于对象存储，通常的定义是：一个Object，由三部分组成（id，metadata，data），id是对象的标识，这个不必多说。所谓的metadata，就是key/value的键值存储，至于用来保存什么信息，由文件系统的语义定义。data就是实际存储的数据。 Ceph的对象，包括四个部分（id，metadata，attribute，data），在Ceph 里，一个Object，实际就对应本地文件系统的一个文件，一个对象的attribute，也是key/value的键值对，其保存在本地文件系统的文件的扩展属性中。对象的metadata就是key/value的键值对，目前Ceph保存在google开源的一个
一种分布式文件系统的设计和实现 程炜烨 (华中科技大学计算机学院湖北武汉 430074) 摘要：分布式文件系统在集群存储中起着重要的作用，。本文详细介绍了一种分布式文件系统的设计和实现，着重叙述了统一名字空间的设计和Linux下客户端文件系统的实现。该分布式文件系统的读写性能比网上邻居有明显的优势。 关键词：集群存储；统一名字空间；超级块；目录项；索引节点 The design and implement of a distribute file system CHENG Weiye (School of Computer Science, Huazhong University of Science and Technology, Wuhan 430074, China) Abstract: Distribute file system plays an important role in cluster storage. The design and implement of the distribute file system is discussed in detail, especially the design of global name space and the implement of file system in Linux. Key words: cluster storage; global name space; super block; directory entry; index node 1引言 为了满足文件存储的新的要求（大容量、高可靠性、高可用性、高性能、动态可扩展性、易维护性），设计一种好的分布式文件系统越来越成为需要。分布式文件系统使得分布在多个节点上的文件如同位于网络上的一个位置便于动态扩展和维护。由于分布式文件系统中的数据可能来自很多不同 的节点，它所管理的数据也可能存储在不同的节点上，这使得分布式文件系统中有很多设计和实现与本地文件系统存在巨大的差别。下面主要讲述分布式文件系统设计和实现中所要面对和解决的主要 问题错误！未找到引用源。。 2软件总体结构 设计一个好的分布式文件系统是集群存储的关键。我们设计的分布式文件系统通过统一名字空间管理使得分布在多个服务器上的文件如同位于网络上的一个位置便于动态扩展和维护。 我们把整个系统主要划分客户端与服务器端两部分。客户端包括MVFS文件系统，CC模块（Client Cache），CNS模块（Client Name Space）,CN模块（Client Network）。服务器端包括SC模块（Server Cache），SNS模块（Server Name Space）,SN模块（Server Network）。应用程序的I/O请求首先送给MVFS文件系统，MVFS文件系统根据文件句柄获得本文件系统的全局文件名并把对文件的访问转换为对CC的访问。CC 收到请求之后，如果在Cache中没有发现对应的数据，则将请求发给CNS 层，CNS层根据全局文件名获得该文件所在的服务器。最终通过CN层将命令发给服务器。服务器端SN层通过网络接待命令后，将命令传递给SNS层负责将全局文件名转化成本地的文件名，然后到SC 层去查找，如果在Cache中找不到，最终会通过本地的文件系统完成对应的I/O 请求。整个系统的总体结构如图1所示。 在服务器端还有一个全局管理程序（心跳协议程序）。通过该心跳协议程序，所有的存储节点的所共享出来的文件构成了整个文件系统的单一的全局逻辑树，从而可以让客户端见到唯一确定的全局逻辑树。
大数据技术与应用 网络与交换技术国家重点实验室 交换与智能控制研究中心 程祥 2016年9月
提纲-大数据存储和管理1. 分布式文件系统 1.1 概述 1.2 典型分布式文件系统 1.3 HDFS 2. 分布式数据库 2.1 概述 2.2 NoSQL 2.3 HBase 2.4 MongoDB（略） 2.5 云数据库（略）
1.1 概述 ?定义：相对于本地文件系统，分布式文件系统是一种通过网络实现文件在多台主机上进行分布式存储的文件系统。 ?分布式文件系统一般采用C/S模式，客户端以特定的通信协议通过网络与服务器建立连接，提出文件访问请求。 ?客户端和服务器可以通过设置访问权限来限制请求方对底层数据存储块的访问。
1.2 典型的分布式文件系统 ?NFS (Network File System) 由Sun微系统公司作为TCP/IP网上的文件共享系统开发，后移植到Linux等其他平台。其接口都已经标准化。 ?AFS (Andrew File System) 由卡耐基梅隆大学信息技术中心(ITC)开发，主要用于管理分部在不同网络节点上的文件。AFS与 NFS不同，AFS提供给用户的是一个完全透明，永远唯一的逻辑路径（NFS需要物理路径访问）。
1.2 典型的分布式文件系统（续） ?GFS（Google File System） 由Google开发，是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。 ?HDFS（Hadoop Distributed File System） HDFS是Apache Hadoop项目的一个子项目，是一个高度容错的分布式文件系统，设计用于在低成本硬件上运行，适合存储大数据，GFS的开源版本。
分布式基础学习
所谓分布式，在这里，很狭义的指代以 Google 的三驾马车，GFS、Map/Reduce、BigTable 为框架核心的分布 式存储和计算系统。通常如我一样初学的人，会以 Google 这几份经典的论文作为开端的。它们勾勒出了分布式存 储和计算的一个基本蓝图，已可窥见其几分风韵，但终究还是由于缺少一些实现的代码和示例，色彩有些斑驳，缺 少了点感性。幸好我们还有 Open Source，还有 Hadoop。Hadoop 是一个基于 Java 实现的，开源的，分布式 存储和计算的项目。作为这个领域最富盛名的开源项目之一，它的使用者也是大牌如云，包括了 Yahoo，Amazon， Facebook 等等（好吧，还可能有校内，不过这真的没啥分量...）。Hadoop 本身，实现的是分布式的文件系统 HDFS，和分布式的计算（Map/Reduce）框架，此外，它还不是一个人在战斗，Hadoop 包含一系列扩展项目， 包括了分布式文件数据库 HBase（对应 Google 的 BigTable），分布式协同服务 ZooKeeper（对应 Google 的 Chubby），等等。。。 如此，一个看上去不错的黄金搭档浮出水面，Google 的论文 + Hadoop 的实现，顺着论文的框架看具体的实现， 用实现来进一步理解论文的逻辑，看上去至少很美。网上有很多前辈们，做过 Hadoop 相关的源码剖析工作，我关 注最多的是这里，目前博主已经完成了 HDFS 的剖析工作，Map/Reduce 的剖析正火热进行中，更新频率之高， 剖析之详尽，都是难得一见的，所以，走过路过一定不要错过了。此外，还有很多 Hadoop 的关注者和使用者贴过 相关的文章， 比如： 这里，这里。 也可以去 Hadoop 的中文站点（不知是民间还是官方...） ，搜罗一些学习资料。 。。 我个人从上述资料中受益匪浅，而我自己要做的整理，与原始的源码剖析有些不同，不是依照实现的模块，而是基 于论文的脉络和实现这样系统的基本脉络来进行的，也算，从另一个角度给出一些东西吧。鉴于个人对于分布式系 统的理解非常的浅薄，缺少足够的实践经验，深入的问题就不班门弄斧了，仅做梳理和解析，大牛至此，可绕路而 行了。。。
一. 分布式文件系统
分布式文件系统，在整个分布式系统体系中处于最低层最基础的地位，存储嘛，没了数据，再好的计算平台，再完 善的数据库系统，都成了无水之舟了。那么，什么是分布式文件系统，顾名思义，就是分布式 文件系统 分布式+文件系统 分布式 文件系统。它包含 这两个方面的内涵，从文件系统的客户使用的角度来看，它就是一个标准的文件系统，提供了一系列 API，由此进 行文件或目录的创建、移动、删除，以及对文件的读写等操作。从内部实现来看，分布式的系统则不再和普通文件 系统一样负责管理本地磁盘， 它的文件内容和目录结构都不是存储在本地磁盘上， 而是通过网络传输到远端系统上。 并且，同一个文件存储不只是在一台机器上，而是在一簇机器上分布式存储，协同提供服务，正所谓分布式。。。 因此，考量一个分布式文件系统的实现，其实不妨可以从这两方面来分别剖析，而后合二为一。首先，看它如何去 实现文件系统所需的基本增删改查的功能。然后，看它如何考虑分布式系统的特点，提供更好的容错性，负载平衡， 等等之类的。这二者合二为一，就明白了一个分布式文件系统，整体的实现模式。。。
I. 术语对照
说任何东西，都需要统一一下语言先，不然明明说的一个意思，却容易被理解到另一个地方去。Hadoop 的分布式 文件系统 HDFS，基本是按照 Google 论文中的 GFS 的架构来实现的。但是，HDFS 为了彰显其不走寻常路的本 性，其中的大量术语，都与 GFS 截然不同。明明都是一个枝上长的土豆，它偏偏就要叫山药蛋，弄得水火不容的， 苦了我们看客。秉承老好人，谁也不得罪的方针，文中，既不采用 GFS 的叫法，也不采用 Hadoop 的称谓，而是 另辟蹊径，自立门户，搞一套自己的中文翻译，为了避免不必要的痛楚，特此先来一帖术语对照表，要不懂查一查， 包治百病。。。
文中所用翻译 主控服务器
HDFS 中的术语 NameNode
GFS 中的术语 Master
术语解释 整个文件系统的大脑，它
1