【论文翻译】Panasas 并行文件系统的可扩展性能（FAST '08）
Panasas 并行文件系统的可扩展性能
Brent Welch, Marc Unangst, Zainul Abbasi, Garth Gibson, Brian Mueller, Jason Small, Jim Zelenka, Bin Zhou
¹Panasas, Inc. ²Carnegie Mellon University
{welch, mju, zabbasi, garth, bmueller, jsmall, jimz, bzhou}@panasas.com
FAST '08: 第六届 USENIX 文件与存储技术会议
摘要
Panasas 文件系统通过对对象存储设备（OSD，Object Storage Device）的并行冗余访问、逐文件 RAID、分布式元数据管理、一致性客户端缓存、文件锁服务以及内部集群管理，提供了一个可扩展、容错、高性能的分布式文件系统。存储系统的集群化设计与客户端驱动 RAID 的结合，通过对跨 OSD 存储节点条带化的文件数据进行并行访问，为大量并发文件系统客户端提供了可扩展的性能。RAID 恢复由元数据管理器集群并行执行，而去簇（declustered）数据放置则在存储系统规模增大时提供了可扩展的 RAID 重建速率。本文给出了存储集群在 I/O、元数据和恢复操作方面的性能测量数据，集群规模从 10 到 120 个存储节点、1 到 12 个元数据节点，文件系统客户端数从 1 到 100 个计算节点。生产安装规模最大可达 500 个存储节点、50 个元数据管理器和 5000 个客户端。
1. 引言
高性能计算（HPC）环境中的存储系统必须在性能上具备可扩展性，以便根据所需负载进行配置。集群技术常被用来提供可扩展性。在存储集群中，多个节点各自控制部分存储，整体分布式文件系统将集群元素组装成一个大型、无缝的存储系统。存储集群可以托管在执行数据处理的同一台计算机上，也可以是专门用于存储的独立集群，通过网络协议供计算集群访问。
Panasas 存储系统是一种专用存储集群，本文介绍其设计及若干性能测量数据以阐明其可扩展性。Panasas 系统是一个生产系统，为世界上一些最大规模的计算集群提供文件服务，应用领域涵盖科学实验室、地震数据处理、数字动画工作室、计算流体动力学、半导体制造和通用计算环境。在这些环境中，数百或数千个文件系统客户端共享数据，并在文件系统上产生极高的聚合 I/O 负载。Panasas 系统设计为支持数千个客户端，存储容量超过一拍字节（petabyte）。
Panasas 系统的独特之处在于：其采用逐文件、客户端驱动的 RAID；并行 RAID 重建；对不同类别元数据（块级、文件级、系统级）的差异化处理；以及基于商用零件的刀片（blade）硬件，并集成 UPS（不间断电源）。当然，系统还有许多其他特性（如对象存储、容错、缓存与缓存一致性以及简化的管理模型），这些并非独有，但对于实现可扩展的系统来说是必不可少的。
2. Panasas 文件系统背景
本节对系统进行简要介绍，为后续章节提供概述。系统的两大核心主题是：对象存储（影响文件系统管理数据的方式），以及组件集群化（使系统在性能和容量上实现可扩展）。
存储集群分为存储节点（storage node）和管理节点（manager node），比例约为 10:1，但该比例可变。存储节点实现对象存储，在 I/O 操作期间由 Panasas 文件系统客户端直接访问。管理节点管理整个存储集群，实现分布式文件系统语义，处理存储节点故障恢复，并通过 NFS 和 CIFS 提供 Panasas 文件系统的导出视图。图 1 展示了系统组件的基本视图。
2.1 对象存储
对象（object）是数据与属性的容器，类似于传统 UNIX 文件系统实现中的 inode（索引节点）。专用存储节点——称为对象存储设备（OSD，Object Storage Device）——在本地 OSDFS 文件系统中存储对象。对象接口采用两级（partition ID / object ID）命名空间寻址对象。OSD 线协议（wire protocol）提供对数据的字节级访问、属性操作、对象的创建与删除以及其他若干专用操作 [OSD04]。我们使用 iSCSI 传输层来承载 OSD 命令，这些命令与目前在 SNIA 和 ANSI-T10 内推进的 OSDv2 标准非常相似 [SNIA]。
Panasas 文件系统构建在对象存储之上。每个文件被条带化到两个或多个对象上，以提供冗余和高带宽访问。文件系统语义由元数据管理器（metadata manager）实现，它们管控客户端对对象的访问。客户端使用 iSCSI/OSD 协议直接对存储节点进行读写操作，I/O 操作绕过元数据管理器并行进行。客户端通过带外 RPC 与元数据管理器交互，以获取存储文件的对象的访问能力和位置信息。条带化文件访问的性能将在论文后面部分介绍。
对象属性用于存储文件级属性，目录则通过存储名称到对象 ID 映射的对象来实现。因此，文件系统元数据保存在对象存储本身，而非元数据节点上的独立数据库或其他形式的存储中。元数据操作将在本文后面描述和测量。
2.2 系统软件组件
主要软件子系统包括：OSDFS 对象存储系统、Panasas 文件系统元数据管理器、Panasas 文件系统客户端、NFS/CIFS 网关，以及整体集群管理系统。
-
Panasas 客户端：一个可安装的内核模块，运行在 Linux 内核内部。该内核模块实现标准 VFS 接口，使客户端主机可以挂载文件系统并通过 POSIX 接口访问存储系统。我们不需要任何补丁即可在 2.4 或 2.6 Linux 内核中运行，并已测试了超过 200 种 Linux 变体。
-
每个存储集群节点运行一个基于 FreeBSD 的公共平台，并附加有用于硬件监控、配置管理和整体控制的额外服务。
-
存储节点使用专用的本地文件系统（OSDFS，Object Storage Device File System），实现对象存储原语。它们实现 iSCSI 目标（target）和 OSD 命令集。OSDFS 对象存储和 iSCSI 目标/OSD 命令处理器均为内核模块。OSDFS 关注传统块级文件系统问题，如高效磁盘臂利用、介质管理（即错误处理）、高吞吐量，以及 OSD 接口。
-
集群管理器（SysMgr）：维护全局配置，控制存储集群中的其他服务和节点。有一个关联的管理应用，提供命令行接口（CLI）和 HTML 界面（GUI）。这些都是在部分管理节点上运行的用户级应用程序。集群管理器负责存储集群中的成员管理、故障检测、配置管理，以及软件升级和系统重启等操作的总体控制 [Welch07]。
-
Panasas 元数据管理器（PanFS）：实现文件系统语义，并管理跨对象存储设备的数据条带化。这是一个运行在每个管理节点上的用户级应用程序。元数据管理器关注分布式文件系统问题，如安全多用户访问、维护一致的文件级和对象级元数据、客户端缓存一致性，以及从客户端、存储节点和元数据服务器崩溃中恢复。容错基于本地事务日志，并复制到不同管理节点上的备份。
-
NFS 和 CIFS 服务：为无法使用我们 Linux 可安装文件系统客户端的主机提供文件系统访问。NFS 服务是在内核内运行的标准 FreeBSD NFS 服务器的调优版本。CIFS 服务基于 Samba，运行于用户级别。这些服务依次使用本地的文件系统客户端实例（运行在 FreeBSD 内核内部）。这些网关服务运行在每个管理节点上，提供集群化的 NFS 和 CIFS 服务。
2.3 商用硬件平台
存储集群节点以刀片（blade）形式实现——由商用零件构成的极为紧凑的计算机系统。刀片集群在一起，提供可扩展的平台。最多 11 个刀片可装入一个 4U（7 英寸高）的机架底座，提供双电源、大容量电池以及一到两个 16 端口千兆以太网（GE）交换机。交换机将刀片上的 GE 端口聚合为 4GE 主干。第二个交换机提供冗余，并连接到每个刀片上的第二个 GE 端口。电池充当 UPS，在电源故障时可为机架底座供电约五分钟，以确保有序关机。任意数量的刀片可以组合成非常大的存储系统。
OSD StorageBlade 模块和元数据管理器 DirectorBlade 模块采用相同的刀片尺寸规格，可安装在相同的机架插槽中。StorageBlade 模块包含一个商用处理器、两块磁盘、ECC 内存和双 GE 网卡。DirectorBlade 模块拥有更快的处理器、更大的内存、双 GE 网卡和一个小型私有磁盘。除元数据管理外，DirectorBlade 还提供 NFS 和 CIFS 服务，其大容量内存在服务这些协议时用作数据缓存。附录 I 中给出了性能实验中使用的不同刀片的详细规格。
任意数量的机架底座可以组成同一个存储集群。一个机架底座通常配有一到两个 DirectorBlade 模块和 9 到 10 个 StorageBlade 模块。配备 10 个 StorageBlade 模块的机架底座在 4U 机架空间中包含 5 到 15 TB 的原始存储。客户安装规模从 1 个机架底座到约 50 个机架底座不等，虽然系统规模没有强制上限。
虽然硬件本质上是商用 PC（即无专用 ASIC），但硬件有两个方面简化了我们的软件设计。第一是机架底座中集成的 UPS，使所有主内存都成为非易失性 RAM（NVRAM）。元数据管理器以低延迟网络协议将日志快速写入内存并反映到备份。OSDFS 对写数据进行缓冲，以便高效管理块分配。UPS 在电源故障后为系统供电数分钟，以便系统在有序关机时得到保护。元数据管理器将日志刷新到本地磁盘，OSDFS 将写入刷新到磁盘。本文稍后将详细描述和测量日志机制。系统监控电池电量，不允许电池电量不足的机架底座投入使用，以避免连续断电时的数据丢失。
硬件的另一重要方面是刀片是现场可更换单元（FRU，Field Replaceable Unit）。如果硬件出现问题，不需要尝试修复刀片，直接更换整个刀片即可。我们最终选择双驱动器存储刀片，这是成本、性能和可靠性之间的折中。以刀片为故障域简化了我们的容错机制，并为系统管理员提供了简单的维护模型。可靠性和数据重建将在本文稍后详细描述和测量。
3. 存储管理
传统存储管理任务包括：将可用存储空间划分为 LUN（逻辑单元，即一个或多个磁盘，或 RAID 阵列的子集），将 LUN 所有权分配给不同主机，配置 RAID 参数，在 LUN 上创建文件系统或数据库，以及将客户端连接到其存储的正确服务器。这是一项劳动密集型场景。我们寻求提供一种简化的存储管理模型，使存储管理员免受这类细节的困扰，让一个兼职管理员就能管理数百 TB 规模的系统。
Panasas 存储系统以 POSIX 接口的文件系统形式呈现，隐藏了大部分存储管理的复杂性。客户端只需一个挂载点即可访问整个系统。/etc/fstab 文件引用集群管理器，客户端由此得知元数据服务实例的位置。管理员可以在系统在线时添加存储，新资源会被自动发现。为管理可用存储，我们引入了两个基本存储概念：称为 BladeSet 的物理存储池和称为 Volume（卷）的逻辑配额树。
BladeSet 是一个或多个机架底座中 StorageBlade 模块的集合，构成一个 RAID 故障域。我们通过第 4.2 节描述的可扩展重建性能来降低大故障域的风险。BladeSet 是其包含的卷的硬物理边界。BladeSet 可以随时扩展，既可以通过添加更多 StorageBlade 模块，也可以通过合并两个现有的 BladeSet 来实现。
Volume（卷） 是具有配额约束并分配给特定 BladeSet 的目录层次结构。配额可以随时更改，容量在使用前不会分配给卷，因此多个卷在其 BladeSet 内竞争空间并按需增长。这些卷中的文件分布在 BladeSet 中所有 StorageBlade 模块中。
卷在文件系统命名空间中以目录形式出现。客户端只需一个挂载点即可访问整个存储系统，卷只是挂载点以下的目录。当管理员创建、删除或重命名卷时，无需更新客户端挂载。
每个卷由单个元数据管理器管理。将元数据管理职责按卷边界（即目录树）划分，主要是为了保持实现简单。我们认为管理员会出于自身原因引入卷（即配额树），这提供了一个简单自然的边界。这样可以推迟解决当父目录由不同于正在其内部创建、删除或重命名文件的元数据管理器控制时出现的多管理器协调问题。我们也有一个合理的元数据管理器崩溃可用性模型：明确定义的子树会离线，而不是对随机文件采样。文件系统恢复检查实现也得到简化：每个卷独立（并行，如果可能）检查，一个卷的错误不影响其他卷的可用性。最后，客户端在读写操作期间绕过元数据管理器，因此元数据管理器的负载已经比存储相同数量文件的传统文件服务器小一个数量级。这降低了细粒度元数据负载均衡的重要性。尽管如此，不均匀的卷利用率可能导致不均匀的元数据管理器利用率。我们的协议允许元数据管理器将客户端重定向到另一个管理器以分散负载，我们计划在未来利用此功能提供更细粒度的负载均衡。
虽然可以拥有一个具有单一 BladeSet 和单一卷的非常大的系统（我们确实有采用这种方法的客户），但我们认为管理员能够配置多个存储池并在其中管理配额是非常重要的。我们最初的模型只有一个存储池：文件被分割成组件对象，这些对象均匀分布在所有可用存储节点上。类似地，元数据管理通过随机将新文件的所有权分配给可用的元数据管理器来进行分布。这类似于 Ceph 模型 [Weil06]。该模型的吸引力在于在可用资源之间平滑负载均衡：只有一个大文件系统，容量和元数据负载会自动平衡。管理员无需担心空间不足，应用程序也能从大型存储系统中获得良好性能。
单一存储池存在两个问题：故障和可用性模型，以及不同用户之间的性能隔离。如果出现足够多的故障导致无法访问某些文件，结果将是整个存储系统中随机抽样的文件变得不可用。即使故障是短暂的（如节点或服务崩溃并重启），也会有可用性不可用的时期。我们希望管理员能够选择将大型系统划分为多个故障域，并在面对故障时拥有明确定义的可用性模型，而不是将整个存储系统置于一个大故障域中。此外，对于大型安装，管理员可以将不同的项目或用户组分配给不同的存储池，从而隔离不同组之间的性能和容量利用率。
我们的存储管理设计反映了大型存储池的性能和容量管理优势、管理员的备份和恢复需求，以及实现复杂性之间的折中。在实践中，我们的客户使用的 BladeSet 规模从单个机架底座到超过 20 个机架底座不等，最大的生产 BladeSet 约为 50 个机架底座，或 500 个 StorageBlade 模块和 50 个 DirectorBlade 模块。然而，最常见的规模在 5 到 10 个机架底座之间。虽然我们鼓励客户引入卷以使系统更好地利用 DirectorBlade 模块，但我们有大型系统（例如 20 个机架底座）只使用单一卷的客户。
3.1 自动容量均衡
当扩展 BladeSet（即添加新的空存储节点）、合并两个 BladeSet，以及在故障后替换存储节点时，都会发生容量不均衡。在后一种情况下，不均衡源于我们的 RAID 重建：它使用每个存储节点上的备用容量，而不是专用一个"热备（hot spare）"节点。这在重建期间提供了更好的吞吐量（见第 4.2 节），但在故障存储节点被替换后会导致系统出现一个新的空存储节点。我们的系统使用两种机制自动平衡 BladeSet 中各存储节点的已用容量：被动均衡和主动均衡。
被动均衡根据存储节点的可用容量改变其被用于文件新组件的概率。这在文件创建时以及其条带大小增加以包含更多存储节点时生效。主动均衡通过将现有组件对象从一个存储节点移动到另一个存储节点，并更新受影响文件的存储映射来完成。在传输期间，文件被存储管理层透明地标记为只读，容量均衡器跳过正在主动写入的文件。因此，容量均衡对文件系统客户端是透明的。
容量均衡可以平衡存储池中的 I/O 负载。我们在大型生产系统中验证了这一点。当然，基于工作负载总是可能存在短暂的热点。避免长期热点非常重要，我们也从一些错误中吸取了教训。我们的方法是对初始数据放置使用均匀随机放置算法，然后在容量均衡期间保持这种分布。系统必须努力实现对象和容量的均匀分布。这比看起来更为微妙，我们发现数据迁移和放置中的偏差可能导致热点。
初始数据放置是均匀随机的，文件的组件落在可用存储节点的子集上。每个新文件都有一个新的随机存储映射。然而，均匀随机分布被被动均衡改变，偏向于在更空的刀片上创建新数据。表面上，这似乎是合理的。不幸的是，如果大型系统中的单个节点由于最近刚被替换而存在大偏差，它最终可能会获得数小时或数天内创建的每个文件的一部分。在某些工作负载中，最近创建的文件可能比几周或几个月前创建的文件更频繁访问。我们的初始实现允许大偏差，偶尔发现这导致了特定存储节点上的长期热点。我们当前的系统将被动均衡的影响限制在均匀随机的百分之几以内，这有助于系统在所有节点接近满时微调容量，但不会导致可能引起热点的大偏差。
我们的另一个偏差是偏向于选择大对象进行主动均衡，因为这更高效。更新文件的存储映射有单文件开销，因此移动一个 1 GB 的组件对象比移动 1000 个 1 MB 的组件对象更高效。然而，考虑一个有相对较少的大文件被广泛条带化、以及大量其他小文件的系统。当从 N 扩展到 N+M 个存储节点（例如从 50 扩展到 60）时，系统应该通过移动少数大对象还是移动大量小对象来平衡容量？如果大文件是热点，偏向它们是一个错误，因为新存储节点可能获得不成比例的热对象。我们发现，从源刀片选择均匀随机的对象样本是避免偏差和意外热点的最佳方式，即使这意味着要移动大量小对象来平衡容量。
4. 对象 RAID 与重建
我们通过使用容错条带化算法（如 RAID-1 或 RAID-5）将文件跨存储在不同存储节点上的对象进行条带化，来防止数据对象或整个存储节点的丢失。小文件被镜像在两个对象上，较大的文件被更广泛地条带化，以提供更高带宽并减少来自奇偶校验信息的容量开销。逐文件的 RAID 布局意味着不同文件的奇偶校验信息不会混合在一起，并且可以轻松允许不同文件在彼此旁边使用不同的 RAID 方案。这一属性以及 OSD 协议的安全机制 [Gobioff97] 使我们能够在客户端直接访问存储节点时对文件强制执行访问控制。它还实现了我们系统中或许最具创新性的方面：客户端驱动的 RAID——即由客户端负责计算和写入奇偶校验数据。OSD 安全机制还允许多个元数据管理器在同一存储设备上管理对象，而无需繁重的协调或相互干扰。
客户端驱动的逐文件 RAID 对大规模存储系统有四个优势：
第一， 通过让客户端为其自身的数据计算奇偶校验，系统的 XOR（异或）计算能力随着客户端数量的增加而扩展。我们在流式写带宽负载下测量了 XOR 处理，发现其占用客户端 CPU 的约 4%，其余部分用于 OSD/iSCSI/TCP/IP 栈和其他文件系统开销。将 XOR 计算从存储系统移至客户端需要一些额外工作来处理故障。客户端负责为其数据和奇偶校验数据生成正确的数据。由于 RAID 方程是逐文件的，一个有问题的客户端只能损坏其自身的数据。然而，如果客户端在写操作期间失败，元数据管理器将清理奇偶校验以确保奇偶校验方程正确。
第二， 客户端驱动 RAID 使客户端可以执行端到端数据完整性检查。数据需要经过磁盘子系统、存储节点上的网络接口、网络和路由器、客户端上的网卡，所有这些传输都可能以极低的概率引入错误。客户端可以选择在读取数据的同时读取奇偶校验数据，并在读操作中验证奇偶校验。如果检测到错误，则重试该操作。如果错误持续存在，则发出警报并使读操作失败。我们使用此功能追踪过不稳定的硬件组件；我们发现了由错误的网卡、错误的驱动器缓存和错误的客户交换机基础设施引入的错误。虽然 ZFS [ZFS] 等文件系统在本地文件系统中维护块校验和，但这无法解决在将信息传输到网络客户端期间引入的错误。通过在客户端内跨存储节点检查奇偶校验，系统可以确保端到端的数据完整性。这是逐文件、客户端驱动 RAID 的另一个新颖特性。
第三， 逐文件 RAID 保护让元数据管理器可以并行重建文件。虽然并行重建在基于块的 RAID 中理论上是可行的，但很少实现。这是因为即使在双端口配置中，磁盘也属于单个RAID 控制器。大型存储系统有多个互不连接的 RAID 控制器。由于 SCSI 块命令集不提供细粒度同步操作，多个 RAID 控制器很难在不进行外部通信的情况下协调在线重建这样复杂的操作。即使可以，如果没有与受影响奇偶校验组中磁盘的连接，其他 RAID 控制器也无法提供帮助。即使在高可用配置中，每个磁盘通常只连接到两个不同的 RAID 控制器，这将潜在加速比限制在 2 倍。
当 StorageBlade 模块发生故障时，拥有该 BladeSet 内卷的元数据管理器确定哪些文件受影响，然后将文件重建工作分配给系统中的所有其他元数据管理器。元数据管理器首先重建自己的文件，但如果它们提前完成或在受影响的 BladeSet 中不拥有任何卷，则可以协助其他元数据管理器。去簇奇偶校验组（Declustered parity groups）[Holland92] 将 I/O 工作负载分散到 BladeSet 中的所有 StorageBlade 模块上。结果是更大的存储集群能够更快地重建丢失的数据。可扩展的重建性能将在本文稍后介绍。
第四， 逐文件 RAID 可以将不可恢复的故障限制在单个文件。RAID-5 中最常见的双重故障场景是在重建失败存储设备期间出现不可恢复读取错误（即增长的介质缺陷）。第二个存储设备仍然健康，但无法读取某个扇区，这阻止了对第一个驱动器丢失扇区的重建，并可能导致整个条带或 LUN 的丢失，具体取决于 RAID 控制器的设计。对于基于块的 RAID，很难或不可能直接将任何丢失的扇区映射回更高级别的文件系统数据结构，因此需要进行完整的文件系统检查和介质扫描来定位和修复损坏。更典型的响应是完全放弃重建。RAID 控制器监控驱动器以清除介质缺陷并避免这种糟糕的情况，Panasas 系统也会进行介质擦洗。然而，对于高容量 SATA 驱动器，在重建驱动器 A 时在驱动器 B 上遇到介质缺陷的概率仍然显著。对于逐文件 RAID-5，这种双重故障意味着只有单个文件丢失，可以轻松识别该特定文件并向管理员报告。虽然基于块的 RAID 系统不得不引入 RAID-6（即能处理两个故障的容错方案），但我们已经能够部署具有大型高性能存储池的高可靠 RAID-5 系统。
4.1 RAID I/O 性能
本节展示 I/O 性能作为存储系统规模、客户端数量和条带配置的函数。展示了流式 I/O 和随机 I/O 性能。
图 2 展示了使用最多 100 个客户端对 1、2、4 和 8 个机架底座存储集群进行的 iozone [Iozone] 流式带宽性能测试。每个客户端运行两个 iozone 实例，以 64 KB 记录大小读写 4 GB 文件。（注意 X 轴不是线性的；从 160 个 I/O 流到 200 个有一个跳跃。）附录 I 总结了实验中使用的硬件详细信息。
这是一个复杂的图表，但有两个基本结果。第一，性能随存储系统规模的增大而线性增加。第二，随着客户端数量的增加，写性能向上扩展并保持平稳，而读性能随客户端数量增加而下降。写性能曲线展示了性能可扩展性：单机架底座系统提供约 330 MB/sec，双机架底座系统提供约 640 MB/sec，四机架底座系统提供约 1280 MB/sec，八机架底座系统峰值约 2500 MB/sec。这对应于 95% 线性的扩展因子。在另一个实验中，一个 30 机架底座系统实现了刚刚超过 10 GB/sec 的读取性能，每个机架底座带宽约 330 MB/sec。
这类结果依赖于客户端和存储节点之间充足的网络带宽。它们还需要大文件的两级 RAID 条带模式以避免网络拥塞 [Nagle04]。对于大文件，系统分配 8 到 11 个存储节点的奇偶校验组，直到所有可用存储节点都被使用。大约 1 GB 的数据（2000 个条带）存储在每个奇偶校验组中，然后轮转到下一个组。当所有奇偶校验组都被使用后，文件绕回到第一个组。系统自动选择奇偶校验组的大小，使整数个奇偶校验组适合可用存储节点，剩余未使用的最少。两级 RAID 模式将 I/O 集中在少量存储节点上，但仍允许大文件扩展到覆盖完整的存储节点集。每个文件都有自己从奇偶校验组到存储节点的映射，这分散了负载并减少了热点。
读写扩展性之间的差异源于 OSDFS 写入数据的方式。它对新数据执行延迟块分配，以便可以批量高效写入。因此，新数据及其相关元数据（即间接块）被流式写入下一个可用的空闲空间，这导致磁盘臂的高效利用。相比之下，读取操作必须寻道才能获取数据，因为数据集被创建为太大以至于无法放入任何缓存中。虽然 OSDFS 执行对象感知的预读，但随着并发读取流数量的增加，优化工作负载变得更加困难，因为每个流可用的预读缓冲量缩小了。
图 3 展示了对具有不同传输大小和不同客户端数量的 4 GB 文件进行混合（即读和写）随机 I/O 操作的 iozone 性能。每个客户端有自己的文件，因此工作集大小随更多客户端增加。变化了两个参数：StorageBlade 模块上的内存量，以及 I/O 传输大小。纵轴显示存储系统的吞吐量，图表比较了不同配置随客户端数量从 1 增加到 6 时的情况。结果表明，StorageBlade 模块上更大的缓存可以显著提高小块随机 I/O 的性能。
我们测试了两种不同的硬件配置：具有 512 MB 内存的 StorageBlade 模块（标记为"0.5 GB"）和具有 2 GB 内存的 StorageBlade 模块（标记为"2 GB"）。每种情况下系统都有 9 个 StorageBlade 模块，因此 StorageBlade 模块上的总内存分别为 4.5 GB 和 18 GB。使用了两种不同的传输大小：64 KB 匹配条带单元大小，4 KB 是 OSDFS 的底层块大小。显然，内存较大的配置能够缓存少量客户端时的大部分或全部工作集。随着客户端数量增加使工作集大小远超缓存，缓存大小的差异就不那么重要了。4 KB 随机 I/O 在缓存不足时吞吐量非常低：单个客户端获得约 1.1 MB/sec（约 280 次 4 KB 操作/秒），4 个客户端的速率下降到 700 KB/sec（约 175 次操作/秒）。混合工作负载中的 4 KB 和 64 KB 写入需要四次 OSD 操作才能完成 RAID-5 对完整条带的更新（两次读取、两次写入）。此外，我们观察到客户端缓存和 OSD 之间由于默认启用以优化流式工作负载的预读和写入聚合优化而产生的额外 I/O 流量。由于 iozone 测试在 4 KB 块和 4 GB 文件情况下每个客户端执行 100 万次 I/O，我们在 512 MB 缓存配置中选择不使用 5 和 6 个客户端进行该测试，因为运行时间太长。
4.2 RAID 重建性能
RAID 重建性能决定了存储节点丢失时系统恢复数据的速度。短重建时间缩短了第二次故障可能导致数据丢失的时间窗口。缩短重建时间有三种技术：减小 RAID 奇偶校验组的大小、去簇奇偶校验组元素的放置，以及使用多个 RAID 引擎并行重建文件。
重建带宽是存储节点被重建时重建数据写入系统的速率。系统必须读取的数据量是写入量的 N 倍，具体取决于 RAID 奇偶校验组的宽度，因此存储系统的整体吞吐量比重建速率高出数倍。更窄的 RAID 奇偶校验组需要更少的读取和 XOR 操作来重建，因此会产生更高的重建带宽。然而，它也会导致更高的奇偶校验数据容量开销，并可能限制正常 I/O 期间的带宽。因此，选择 RAID 奇偶校验组大小是容量开销、在线性能和重建性能之间的权衡。
理解去簇最容易通过图来说明。在图 4 中，每个奇偶校验组有 4 个元素，用放置在每个存储设备中的字母表示。它们分布在 8 个存储设备上。奇偶校验组大小与可用存储设备之间的比率是去簇比率，在本例中为 1/2。在图中，大写字母表示所有共享第 2 个存储节点的奇偶校验组。如果第 2 个存储设备发生故障，系统必须读取其奇偶校验组的存活成员来重建丢失的元素。可以看到这些奇偶校验组的其他元素占据了每个其他存储设备的约 1/2。
对于这个简单示例，可以假设每个奇偶校验元素大小相同，因此所有设备都均匀填充。在实际系统中，组件对象的大小会因整体文件大小而异，尽管奇偶校验组的每个成员大小非常接近。每个设备上将有数千或数百万个对象，Panasas 系统使用主动均衡在存储节点之间移动组件对象以平衡容量。
去簇意味着重建需要读取每个设备的一个子集，比例大约与去簇比率相同。读取的数据总量在有无去簇的情况下相同，但有去簇时它分散在更多设备上。写入重建的元素时，同一奇偶校验组的两个元素不能位于同一存储节点。去簇留下许多存储设备可用于重建的奇偶校验元素，随机化每个文件的奇偶校验组放置使系统能够将写 I/O 分散到所有存储上。因此，去簇 RAID 奇偶校验组具有将固定量的重建 I/O 分散到更多存储设备上的重要属性。
拥有逐文件 RAID 允许 Panasas 系统通过将不同文件分配给不同的 DirectorBlade 模块，在可用的 DirectorBlade 模块之间划分工作。这种划分是动态的，采用简单的主/工作者模型，元数据服务将自己提供为工作者，每个元数据服务充当其实现的卷的主机。通过在所有 DirectorBlade 模块上并行进行重建，系统可以利用更多 XOR 吞吐量并利用通过去簇获得的额外 I/O 带宽。
图 5 绘制了存储集群规模从 1 个 DirectorBlade 模块和 10 个 StorageBlade 模块增长到 12 个 DirectorBlade 模块和 120 个 StorageBlade 模块时的重建性能。每个机架底座有 1 个 DirectorBlade 模块（1.6 GHz Xeon）和 10 个 StorageBlade 模块。在本实验中，系统填充了 100 MB 文件或 1 GB 文件，图表中的每个字形代表一次单独的测试。去簇比率从 0.9 到 0.075 不等，产生的重建带宽从 10 MB/sec 到 120 MB/sec 不等。去簇和并行重建使重建性能随系统增大几乎线性增加。
在 8 和 10 个机架底座时性能降低源于更宽的条带大小。系统自动从 8 到 11 中选择条带宽度，最大化使用存储节点数量的同时至少留一个备用位置。例如，在具有 10 个 StorageBlade 模块和 1 个分布式备用的单机架底座系统中，系统将使用 9 的条带宽度。分布式备用允许重建在不替换故障存储节点的情况下进行：每个文件的存储映射至少跳过一个可用存储节点，为该文件创建一个虚拟备用位置，可用于存储故障组件的重建副本。每个文件都有自己的备用位置，这将备用分散到整个 BladeSet 中。系统在每个存储节点上保留容量以允许重建。在 80 个存储节点和 1 个分布式备用的情况下，系统选择条带宽度 11，以便 7 个奇偶校验组适合，留下 3 个未使用的存储节点。宽度 10 无法使用，因为没有未使用的存储节点。表 1 列出了奇偶校验组大小（即条带宽度）作为存储池规模的函数。
12 机架底座结果中的变异性来自使用 1 GB 文件和多个卷的运行。在此测试中，受存储节点故障影响的文件数量在不同卷之间差异很大，因为每个存储节点上只使用了 30 GB 的空间，每个元数据管理器只需重建 25 到 40 个文件。元数据管理器完成自己的卷和开始为其他元数据管理器工作之间有一个小延迟；结果是在重建快结束时并非每个元数据管理器都被充分利用。重建接近满的 StorageBlade 时，此延迟可以忽略不计，但在我们的测试中它足够大以影响结果。由于我们通过测量总重建时间并除以重建的数据量来计算带宽，这种不均匀的利用率使结果偏低。我们通过填充多 10 倍数量的 100 MB 文件（这导致文件在卷所有者之间分布更均匀）或通过使用单个卷来避免调度问题，获得了更高的吞吐量和更少的变异性。
图 6 显示了 RAID 奇偶校验组宽度对重建速率的影响。如果奇偶校验条带宽度为 6，则读取 5 个存活元素来重新计算缺失的第 6 个元素。如果奇偶校验条带只有 3 宽，则只读取 2 个存活元素来重新计算缺失元素。即使读取可以并行发出，更宽的条带也有更多的内存带宽相关读取和更多的 XOR 工作。因此，更窄的奇偶校验条带重建速度更快。实验证实了这一点。
我们测量了两个系统：一个有三个 DB-100 DirectorBlade 模块和 8 个 SB-500a-XC StorageBlade 模块，此配置中最大条带宽度为 7（允许备用）；另一个有四个 DB-100a DirectorBlade 模块和两个机架底座中的 18 个 SB-500a-XC StorageBlade 模块，最大条带宽度为 8。重建带宽随更窄的条带而增加，因为系统必须读取更少的数据来重建相同的量。结果还表明，拥有更多 DirectorBlade 模块可以提高重建速率，这是因为有更多的"重建引擎"可以更好地利用系统中的可用带宽。这些结果表明，图 5 中所示的大型系统的重建性能在每个机架底座配备 2 个 DirectorBlade 模块时会更高，因为这些结果使用了旧的第一代 DirectorBlade 模块，性能会超过两倍。
5. 元数据管理
我们的系统中有几类元数据。这包括从对象 ID 到块地址集合的映射、文件到对象集合的映射、文件系统属性（如 ACL 和所有者）、文件系统命名空间信息（即目录），以及关于存储集群本身的配置/管理信息。一种方法是选择一种通用机制（可能是关系数据库），并使用该设施存储所有这些信息。这将可扩展性、可靠性和性能问题从存储系统转移到数据库系统，但这使得针对每种类型元数据的独特需求优化元数据存储变得更加困难。与此相反，我们为每种类型的元数据提供了具体实现。我们的方法在对象存储设备和元数据管理器之间分布元数据管理，以提供可扩展的元数据管理性能，并允许为每种元数据类型选择最佳机制。
5.1 块级元数据
块级元数据由我们优化存储对象的文件系统 OSDFS 在内部管理。OSDFS 使用浮动块分配方案，其中数据、块指针和对象描述符被批量组成大型写操作。写缓冲区由集成 UPS 保护，在电源故障或系统崩溃时刷新到磁盘。我们的块分配算法类似于 WAFL [Hitz94] 和 LFS [Rosenblum90]，但与 LFS 不同，没有用于压缩空闲空间的清理器。分片（Fragmentation）在早期使用首次适应（first-fit）块分配器的 OSDFS 版本中是一个问题，但在后来使用修改后的最佳适应（best-fit）分配器的版本中得到了显著缓解。
OSDFS 使用改进的 BTree 数据结构存储更高级别的文件系统数据结构，如分区和对象表。每个对象的块映射使用传统的直接/间接/双重间接方案。空闲块由专有的位图类数据结构跟踪，该结构针对写时复制（copy-on-write）引用计数进行了优化，这是 OSDFS 集成支持对象级和分区级写时复制快照的一部分。
块级元数据管理消耗了文件系统实现中的大部分处理周期 [Gibson97]。通过将存储管理委托给 OSDFS，Panasas 元数据管理器的工作量比等效 SAN 文件系统元数据管理器少一个数量级，后者必须跟踪系统中的所有块。
5.2 文件级元数据
块层之上是关于文件的元数据。这包括用户可见信息（如所有者、大小和修改时间），以及标识哪些对象存储文件以及数据如何跨这些对象条带化的内部信息（即文件的存储映射）。我们的系统将此文件元数据存储在用于存储文件数据的 N 个对象中的两个对象的属性中。其余对象具有基本属性（如各自的长度和修改时间），但更高级别的文件系统属性只存储在两个属性存储组件上。注意，文件的长度和修改时间可以从每个对象上的相应属性推导出来，但出于性能考虑，我们存储这些属性的明确文件级版本，与对象级属性不同。
还记得由于将文件创建偏向空的替换刀片而导致的热点问题吗？这是因为前两个组件对象存储文件级属性，因此它们看到的 SetAttributes 和 GetAttributes 流量比其余组件更多。文件总是从这两个属性存储组件开始镜像，所以文件创建偏差正在制造元数据热点。
文件名在类似传统 UNIX 文件系统的目录中实现。目录是存储目录条目数组的特殊文件。目录条目用 <serviceID, partitionID, objectID> 元组标识文件，还包括两个
客户端被允许读取、缓存和解析目录，或者它们可以使用对元数据管理器的 Lookup RPC 将名称转换为 <serviceID, partitionID, objectID> 元组和
文件操作可能需要几个对象操作。图 7 显示了创建文件的步骤。元数据管理器保持本地日志，记录进行中的操作，以便在更新多个对象时从对象故障和元数据管理器崩溃中恢复。例如，创建文件是一个相当复杂的任务，需要更新父目录以及创建新文件。有 2 个 Create OSD 操作来创建文件的前两个组件，以及 2 个 Write OSD 操作，每个写到父目录的一个副本。作为性能优化，元数据服务器还向客户端授予文件的读写访问权限，并将适当的能力作为 FileCreate 结果的一部分返回给客户端。服务器记录这些写能力以支持客户端在写文件时崩溃的错误恢复。注意，目录更新（步骤 7）发生在回复之后，因此许多目录更新可以批量在一起。延迟更新由 op-log 记录保护，在成功完成目录更新后的步骤 8 中删除。
元数据管理器维护一个 op-log（操作日志），记录正在进行中的对象创建和目录更新。此日志条目在操作完成时删除。如果元数据服务崩溃并重启，或者故障事件将元数据服务移动到不同的管理节点，则处理 op-log 以确定在故障时哪些操作处于活动状态。元数据管理器向前或向后回滚操作以确保对象存储一致。如果还没有生成对操作的回复，则回滚操作。如果已经生成了回复但还有待处理的操作（例如，目录更新），则向前回滚操作。
写能力存储在 cap-log（能力日志）中，以便元数据服务器启动时知道哪些文件处于忙碌状态。除了 FileCreate 返回的"随带"写能力外，客户端还可以执行 StartWrite RPC 来获取单独的写能力。当客户端通过 EndWrite RPC 释放写能力时，cap-log 条目被删除。如果客户端在 I/O 期间报告错误，则会创建修复日志条目并安排文件进行修复。读写能力由客户端跨多个系统调用缓存，进一步减少元数据服务器流量。
我们的日志实现使用了一种快速（3 微秒更新）内存中日志机制，该机制在系统关闭、电源故障和软件故障（包括内核崩溃）时保存到磁盘。在故障转移配置中，此日志通过低延迟协议（千兆以太网上 90 微秒更新）同步反映到远程对等方的内存中。软件崩溃通常通过重启和从本地日志恢复来处理。如果硬件故障或 OS 挂起禁用了 DirectorBlade 模块，则其备份接管并从日志副本中恢复。
如果日志不可恢复，或者没有备份，那么崩溃可能使分布式对象存储处于不一致状态（例如，部分创建的文件）。这些不一致性在正常操作期间被发现并容忍。在某些情况下，系统可以在文件打开操作期间修复对象。在其他情况下，系统只是隔离可疑对象，稍后可以通过（离线）文件系统恢复检查工具进行修复，该工具扫描对象存储、修复不一致性并向前或向后回滚进行中的操作。可选的恢复过程以约 800 个文件/秒的速度运行，可以在不同 DirectorBlade 模块的多个卷上并行运行。
电池支持内存中快速日志与远程备份日志复制、在对象上存储元数据、以及离线修复过程的结合，是一个鲁棒的设计点。内存中日志之所以可行，是因为集成 UPS 使系统可以安全关闭。远程备份防范 DirectorBlade 模块的彻底硬件故障。然而，在任何复杂产品中，软件故障都是风险。我们的元数据管理器作为用户级应用程序运行，因此可以透明地终止并重启，并基于其日志进行恢复。使用内核驻留客户端的 NFS 网关可能是内核崩溃的来源。大多数这些崩溃都是"干净"的内核崩溃，系统能够保存内存中日志内容。最后，如果一切都失败，我们知道可以运行恢复过程，将文件系统恢复到一致状态。令人欣慰的是，即使所有元数据管理器停止工作，我们仍然可以恢复存储系统，因为所有文件元数据都驻留在存储节点本身。
5.3 文件元数据性能
我们使用 Metarates 应用程序 [Metarates] 测量了元数据性能。这是一个 MPI 应用程序，协调来自多个客户端的文件系统访问。图 8 显示了 15 个 2.4 GHz Xeon 客户端对单个 DirectorBlade 模块进行的 Create 和 Utime 性能。Create 操作创建一个空文件，每个客户端在自己的目录中工作。Utime 操作设置文件的时间戳属性。结果同时给出了 Panasas DirectFLOW 协议（DF）和使用 DirectorBlade 模块上网关客户端的 NFS 协议的性能。测量了两种不同的 DirectorBlade 型号：DB-100 和 DB-100a。我们还测量了在本地连接 RAID 阵列上运行 Linux 的 NFS 服务器。
Panasas 协议在 Utime 上比 NFS 表现更好，原因是客户端管理属性的方式。Panasas 客户端可以可靠地缓存属性，因为有状态 Panasas 元数据管理器的回调协议。NFS 客户端在完成 SetAttr 之前需要用 GetAttr 操作重新验证其缓存，因此它们执行两倍数量的服务器操作来完成一次 Utime 操作，导致客户端吞吐量降低。
在 Linux NFS 测试中，文件服务器在 CREATE 和 SETATTR 操作期间进行同步磁盘写入，这是 NFSv3 标准的稳定存储条款 [Pawlowski94] 所要求的，有明显的性能影响。在 Panasas 系统中，写入在 StorageBlade 模块上的受保护内存中缓冲。更新以日志方式流式传输，操作时间与磁盘 I/O 解耦。我们的创建算法非常健壮，日志记录驻留在两个 DirectorBlade 模块上，对象在操作返回到客户端之前在两个 StorageBlade 模块上创建。单次创建的延迟约为 2 毫秒。
一些 NFS 服务器通过将 Create 记录在 NVRAM 并立即返回来优化它。Panasas 系统不这样做，因为客户端在 Create 操作从元数据管理器返回后必须能够直接写入存储节点。虽然我们考虑过将创建能力授予客户端作为优化，但我们避免了它给协议增加的额外复杂性。我们的元数据管理器在返回客户端之前在存储上创建对象。
图 9 显示了随客户端数量增加的 Create 和 Utime 性能。这些操作涉及到 StorageBlade 模块的 I/O 操作。Create 执行两次对象创建和两次向父目录的写入。Utime 对两个对象执行 set attributes。DirectorBlade 和机架底座对应于第一张图表中的"DB-100"。2.4 GHz DirectorBlade 模块在 15 个客户端时以 840 次创建/秒和 2000 次 utime/秒接近饱和。
图 10 显示了 Stat 性能。基准测试让单个客户端创建所有文件，然后所有客户端执行其 Stat 操作。第一个客户端总是命中其缓存，因此获得 45,000 Stat ops/sec。其他客户端获得 1,200 到 2,000 ops/sec，因为它们的操作涉及服务器往返。图表以 Metarates"聚合吞吐量"绘制，通过将最慢的客户端乘以总客户端数获得。这个指标可能看起来不公平，但它代表了屏障同步 MPI 应用程序的有效吞吐量。例如，在两个客户端时，一个以 1,777 ops/sec 运行，另一个以 45,288 ops/sec 运行，聚合报告为 3,554 ops/sec。
5.4 系统级元数据
最后一层元数据是关于整个系统本身的信息。一种可能性是将这些信息存储在对象中，并通过发现协议引导系统。该方法最困难的方面是推理故障模型。系统必须能够在只有部分功能的情况下启动和管理。我们选择了一种模型，其中有一小组复制的系统管理器，每个存储系统配置元数据的副本。
每个系统管理器维护一个本地数据库，独立于对象存储系统。我们使用 Berkeley DB 存储表示我们系统模型的表。不同的系统管理器实例是复制集的成员，使用 Lamport 的部分时间议会（PTP，Part-Time Parliament）协议 [Lamport98] 做出决策并更新配置信息。集群配置有一个、三个或五个系统管理器，使投票法定人数为奇数，网络分区将导致少数系统管理器禁用自身。
系统配置状态包括静态状态（如系统中刀片的身份）以及动态状态（如各种服务的在线/离线状态和与不同系统组件相关的错误条件）。每个状态更新决策，无论是更新管理员密码还是激活服务，都涉及根据 PTP 协议进行一轮投票和一轮更新。数据库更新在 PTP 事务中执行，以保持数据库同步。最后，系统在几个其他刀片上保留系统配置数据库的备份副本，以防所有系统管理器刀片灾难性丢失。
刀片配置作为每个刀片启动序列的一部分从系统管理器拉取。初始 DHCP 握手传达系统管理器的地址，此后每个刀片上的本地 OS 通过 RPC 从系统管理器拉取配置信息。
集群管理器实现有两层。下层 PTP 层管理投票轮次，并确保分区或新添加的系统管理器将与法定人数同步。上层应用程序层使用投票和更新接口做出决策。复杂的系统操作可能涉及几个步骤，系统管理器必须跟踪进度，以便能够容忍崩溃并适当地回滚或向前滚。
例如，创建卷（即配额树）涉及：创建顶级目录的文件系统操作、在每个 StorageBlade 模块上的 OSDFS 中创建对象分区的对象操作、激活适当元数据管理器的服务操作，以及反映卷添加的配置数据库操作。恢复通过两个 PTP 事务来实现。初始 PTP 事务确定是否应该创建卷，并创建一个标记为未完成的卷记录。然后系统管理器执行所有必要的服务激活、文件和存储操作。当这些全部完成后，执行最终 PTP 事务来提交操作。如果系统管理器在最终 PTP 事务之前崩溃，它将在下次重启时检测到未完成的操作，然后向前或向后回滚操作。
我们使用一个简单测试程序测量了更新配置数据库中条目的简单 PTP 事务，该程序执行 1000 次这些操作。更新的成本（包括到系统管理器的 RPC、PTP 投票轮次和对单个表的 BDB 更新）在我们的 2.4 GHz DirectorBlade 模块上约为 7 毫秒。该成本主要由 BDB 更新中的同步磁盘写入决定。我们启用了同步磁盘写入（尽管有 UPS），以使系统配置数据库具有高可靠性。当有 2、3、4 或 5 个成员的复制集时，成本翻倍为 14 毫秒，因为 PTP 实现执行了额外的表更新。PTP 法定人数主席并行向法定人数成员执行 RPC，因此在这些复制规模下，有 2 个或 5 个复制集成员之间没有性能差异。
注意，文件系统元数据管理器执行的日志记录与集群管理器执行的投票事务之间有两到三个数量级的差异。内存中日志更新为 3 微秒，或通过网络反映需要 90 微秒。PTP 投票轮次和 BDB 数据库更新为 7 到 14 毫秒。这些不同机制使我们拥有一个非常健壮的集群管理系统和一个非常高性能的文件系统。
6. 相关工作
目前在高性能计算集群中使用的主要文件系统有 Panasas 文件系统、Lustre [Lustre02]、GPFS [Schmuck02] 和 PVFS2 [PVFS2][Devulapalli07][Yu05]。Cope 对 Lustre、GPFS 和 PVFS2 进行了一些性能比较 [Cope06]。Lustre 与 Panasas 有类似的整体架构，两个系统都基于 CMU NASD 工作的思想。Lustre 使用相对较大的对象存储服务器（OSS 服务器和 OST 对象存储），可以在 OST 上进行简单条带化，但没有主动容量均衡或额外的奇偶校验信息。PVFS2 也在存储节点间进行简单条带化，没有冗余。GPFS 和 Lustre 依赖基于块的 RAID 控制器来处理磁盘故障，而 PVFS2 通常在计算节点上使用本地文件系统。
集群 NFS 系统包括 Isilon [Isilon]、NetApp GX [Klivanski06] 和 PolyServe [Polyserve]。这些 NFS 系统可扩展性有限，因为每个客户端必须通过单个访问点漏斗其请求，然后将请求转发到拥有数据的节点。并行 NFS 扩展 [Hildebrand05]（将成为 NFSv4.1 的一部分）可能有助于这些系统克服此限制。来自 DirectorBlade 模块的 Panasas NFS 导出与这些系统具有类似特性。
SAN 文件系统（例如，CXFS [Shepard04]、IBRIX、MPFS/MPFSi、Oracle OCFS2 [Fasheh06]、GFS2 [GFS2]、ADIC StorNext）具有非标准客户端、元数据管理器节点，并且是面向块的。这些从单主机文件系统演化而来，通过引入块管理器（即元数据服务器）。块管理通常是可扩展性的限制，因为元数据管理器必须跟踪任何规模系统中的数十亿个块。
GPFS 也是一种 SAN 文件系统，但其分布式锁管理方案和使用大块（256K 到 4MB）帮助它扩展以支持更大的集群。GPFS 使用集中式令牌管理器，该管理器委托对块、inode、属性和目录条目的细粒度锁。锁委托让第一个访问资源的客户端成为其锁管理器，从而分散元数据管理负载。然而，有些工作负载会在系统协商锁所有权时在锁所有者和令牌管理器之间产生大量流量。节点可以同时是客户端和服务器，尽管在大型系统中通常有更多的纯客户端节点和控制存储的节点子集。服务通过故障转移协议和驱动器双端口实现容错。
有几个研究项目探索对象存储，包括 Ceph [Weil06] 和 Ursa Minor [Abd-El-Malek05]。这些系统具有略有不同的对象语义和自定义协议。Ursa Minor 将版本控制作为其对象的基本属性。Ceph 使用基于哈希的分布方案，其对象服务器相互传播副本（即有冗余但无条带化）。Lustre 使用分布式锁管理器协议，其中客户端、OSS 和元数据管理器都参与。Panasas 对象模型基于标准 iSCSI/OSD 命令集，我们期望它成为下一代商用存储设备的一部分。
在多个研究系统中评估了跨数据服务器条带化以提高带宽。在 Zebra 文件系统 [Hartman93] 中，客户端会生成包含其对许多文件的写入日志的数据流。此日志流被条带化到各服务器上，并生成奇偶校验组件以允许恢复。这种方法将所有文件的奇偶校验信息混合在日志中，不允许调整每个文件的 RAID 配置。Cheops 并行文件系统在 NASD 上分层，确实提供了逐文件条带化，但没有逐文件 RAID [Gibson98]。Isilon 跨其存储节点条带化文件，并使用 RAID 和 Reed Solomon 编码来防止丢失对象。然而，Isilon 的性能受其 NFS 接口限制。RAIF 系统 [Jukov07] 将文件映射到多个文件系统并允许条带化，由客户端的可堆叠文件系统实现。然而，该工作没有描述如何处理多个客户端对共享文件的更新。Lustre 使用简单的 RAID-0 跨对象存储服务器的条带化，依赖服务器内的 RAID 从磁盘故障中恢复，依赖故障转移和双端口驱动器处理服务器故障。最新版本的 NetApp GX 可以跨存储节点条带化文件和卷，还提供了在服务器之间迁移（即复制）文件集以转移负载的设施，以及配置卷的只读副本用于负载共享的能力——这些类似于 AFS 引入的特性 [Howard88]。Panasas 条带化方法专门设计为提供可扩展的性能，以支持数千个活跃客户端共享同一组文件的非常大的系统。
Google FS [Ghemawat03] 是一种在应用程序专用库中实现的用户级文件系统。Google FS 使用复制实现容错，以容忍存储节点的丢失。客户端负责将数据推送到副本，然后在更新完成时通知元数据管理器。Google FS 提供应用程序专用的追加语义以支持并发更新。Panasas 拥有完全序列化的更新以提供 POSIX 语义，以及另一种并发写入模式，优化了来自多个并发客户端的对单个文件的交错步幅写入模式。
在这些系统中，只有 Panasas、Isilon、Google 和 Ceph 在不同存储节点上使用冗余数据来从驱动器故障中恢复。其他系统使用 RAID 控制器、存储节点内的软件 RAID 或根本没有冗余。另一个区别是元数据管理在节点之间的划分。Panasas 按文件树划分所有权，允许多个元数据管理器管理整个系统。大多数其他系统有单个元数据管理器，包括 Lustre、IBRIX 和其他 SAN 文件系统。GPFS 有一种混合方案，具有单个令牌管理器可以委托元数据责任。Ceph 使用细粒度哈希方案来分配元数据所有权。
7. 结论
本文介绍了 Panasas 并行文件系统的设计，并给出了若干性能测量数据以阐明其可扩展性。该设计使用运行 OSDFS 对象存储的存储节点，以及运行文件系统元数据管理器、集群管理器和可以通过 NFS 和 CIFS 重导出的 Panasas 文件系统客户端的管理器节点。可扩展性来自每个存储节点的均衡性，包括磁盘、CPU、内存和网络带宽资源。Panasas 存储集群是块分配的并行机器，因为每个存储节点私有地管理自己的驱动器；它也是 RAID 重建的并行机器，因为每个管理刀片参与分布在存储集群中的去簇奇偶校验组的重建。
良好性能来自于利用非易失性内存隐藏延迟和保护缓存，以及在存储集群内的存储节点和管理节点之间在块级、文件级和系统级分配文件服务器元数据的能力。将文件条带化到具有逐文件 RAID 保护的对象上，允许在拥有多个客户端的环境中以及对于故障 OSD 的重建速率提供可扩展的性能。我们展示了存储集群中从 11 个节点到 132 个节点、文件系统客户端从 1 到 100 个计算节点的 I/O 和元数据性能结果。
附录 I：实验细节
本节总结了不同实验中使用的硬件配置。由于我们在实验室中拥有跨越 3 代产品的各种硬件，一些实验使用不同的硬件。
StorageBlade 模块包含一个相对低功耗的 x86 处理器、两块磁盘（250 GB、500 GB 或 750 GB 7200 RPM SATA 驱动器）、512 MB 或 2 GB ECC 内存和双 GE 网卡。DirectorBlade 模块具有更快的 x86 处理器、4 GB ECC 内存、双 GE 网卡和一个小型 PATA 或 SATA 磁盘。附录中列出了实验中使用的每种刀片型号的具体配置（见表 2）。注意，尽管时钟速度较慢，DB-100a 中的 CPU 在我们的代码上比 DB-100 中的 CPU 快约 30%。
客户端为单 CPU，2.4 GHz 或 2.8 GHz Xeon，配 1 GE 网卡。
网络环境为 1GE，使用 Force10 E1200 作为核心交换机。客户端节点直接连接到核心交换机。每个机架底座有 4 GE 主干连接到核心交换机（除非另有说明）。
实验 1：不同规模存储系统的客户端扩展。使用最多 100 个客户端，每个客户端运行两个 iozone 实例。使用标志 -i 0 -i 1 -e -c -r 64k -s 5g -w 和将两个线程放在每个客户端上的 -+m clients 文件。StorageBlade 模块为 SB-160。每个机架底座有一个第一代 DB 模块和 10 个 StorageBlade 模块，但此测试中只涉及单个元数据服务。
实验 2：随机 I/O 与存储节点缓存内存和客户端数量。使用 iozone 标志 -i 0 -i 1 -i 2 -i 8 -s 4g 并报告混合 I/O 数量。有 9 个 SB-500a 或 SB-500a-XC StorageBlade 模块和 2 个 DB-100 DirectorBlade 模块，但只有一个 DirectorBlade 处于活动状态。机架底座只有一个 GE 上行链路。
实验 3：可扩展 RAID 重建。10 到 120 个 SB-160 StorageBlade 模块，1 到 12 个 DB DirectorBlade 模块。测量故障存储节点上使用的容量，除以系统报告的完成重建的挂钟时间。
实验 4：RAID 重建与条带宽度。3+8 系统有三个 DB-100 DirectorBlade 模块和 8 个 SB-500a-XC StorageBlade 模块。4+18 有四个 DB-100a DirectorBlade 模块和两个机架底座中的 18 个 SB-500a-XC StorageBlade 模块。
实验 5：Metarates 性能。两种不同的 DirectorBlade 为 DB-100 和 DB-100a。NFS 服务器运行 Red Hat Enterprise Linux 4（2.6.9-42.ELsmp）在一台 4 路 2.6 GHz Opteron 8218 机器上，配备四个 10K RPM SAS 驱动器，RAID-0 配置和 ext3 文件系统。
参考文献
[Abd-El-Malek05] Michael Abd-El-Malek 等，Ursa Minor: Versatile Cluster-based Storage，FAST '05，San Francisco，CA，December 2005。
[Cope06] J. Cope, M. Oberg, H.M. Tufo, and M. Woitaszek，Shared Parallel File Systems in Heterogeneous Linux Multi-Cluster Environments，LCI International Conference on Linux Clusters，2006。
[Devulapalli07] A. Devulapalli 等，Integrating Parallel File Systems with Object-Based Storage Devices，SC 2007，Reno，NV，November 2007。
[Fasheh06] Mark Fasheh，OCFS2: The Oracle Clustered File System Version 2，2006 Linux Symposium，pp 289-302。
[Ghemawat03] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung，The Google File System，SOSP '03，pp 20-43。
[Gibson97] Garth A. Gibson 等，File Server Scaling with Network-Attached Secure Disks，SIGMETRICS '97，Seattle WA，pp 272-284。
[Gibson98] G. A. Gibson 等，A Cost-Effective, High-Bandwidth Storage Architecture，ASPLOS-VIII，San Jose，October 1998。
[Gobioff97] H. Gobioff, G. Gibson, D. Tygar，Security for Network Attached Storage Devices，TR CMU-CS-97-185，October 1997。
[Hartman93] J. Hartman and J. Ousterhout，The Zebra Striped Network File System，SOSP '93，pp 29-43，December 1993。
[Hildebrand05] D. Hildebrand, P. Honeyman，Exporting Storage Systems in a Scalable Manner with pNFS，MSST 2005。
[Hitz94] D. Hitz, J. Lau, and M. Malcolm，File System Design for an NFS File Server Appliance，Winter 1994 USENIX Conference，San Francisco，CA，January 1994，pp 235-246。
[Holland92] Mark Holland, Garth Gibson，Parity Declustering for Continuous Operation in Redundant Disk Arrays，ASPLOS '92。
[Howard88] J.H. Howard 等，Scale and Performance in a Distributed File System，ACM Trans. Comput. Syst., Vol. 6 No. 1，pp 51-81，Feb. 1988。
[Jukov07] Nikolai Joukov 等，RAIF: Redundant Array of Independent Filesystems，IEEE MSST 2007。
[Klivansky06] Miroslav Klivansky，Introduction to Data ONTAP GX，http://www.netapp.com/library/tr/3468.pdf，April 2006。
[Lamport98] L. Lamport，The Part-Time Parliament，ACM Trans. Comput. Syst., Vol. 16 No. 2，pp 133-169，1998。
[Lustre02] Cluster File Systems Inc.，Lustre: A Scalable High-Performance File System，lustre.org，2002。
[Nagle04] David Nagle, Denis Serenyi, Abbie Matthews，The Panasas ActiveScale Storage Cluster，SC '04，November 2004。
[OSD04] Object-Based Storage Device Commands (OSD)，ANSI INCITS 400-2004。
[Pawlowski94] B. Pawlowski 等，NFS Version 3: Design and Implementation，Summer 1994 USENIX Technical Conference，pp 137-151，1994。
[Rosenblum90] M. Rosenblum, J. Ousterhout，The LFS Storage Manager，Summer 1990 USENIX，Anaheim，CA，June 1990，pp 315-324。
[Schmuck02] Frank Schmuck, Roger Haskin，GPFS: A Shared-Disk File System for Large Computing Clusters，FAST '02。
[Shepard04] Laura Shepard, Eric Eppe，SGI InfiniteStorage Shared Filesystem CXFS，2004。
[Weil06] Sage Weil 等，Ceph: A Scalable High-Performance Distributed File System，OSDI '06，November 2006。
[Welch07] Brent Welch，Integrated System Models for Reliable Petascale Storage Systems，Petascale Data Storage Workshop，SC '07，Reno，NV，November 2007.
浙公网安备 33010602011771号