架构概述
NetApp解决方案 上的BeeGFS包括用于确定支持经验证的工作负载所需的特定设备、布线和配置的架构设计注意事项。
构建块架构
根据存储要求、可以使用不同的方式部署和扩展BeeGFS文件系统。例如、以大量小文件为主要特征的使用情形将受益于额外的元数据性能和容量、而大文件较少的使用情形则可能有利于提高实际文件内容的存储容量和性能。这些多种注意事项会影响并行文件系统部署的不同维度、从而增加了文件系统设计和部署的复杂性。
为了应对这些挑战、NetApp设计了一个标准的构建块架构、用于横向扩展其中的每个方面。通常、BeeGFS组件部署在以下三种配置文件之一中:
-
一个基础组件、包括BeeGFS管理、元数据和存储服务
-
BeeGFS元数据加上存储组件
-
仅供BeeGFS存储使用的组件
这三个选项之间的唯一硬件更改是使用较小的驱动器来获取BeeGFS元数据。否则、所有配置更改将通过软件应用。借助Ansible作为部署引擎、为特定组件设置所需的配置文件可以使配置任务变得简单明了。
有关更多详细信息、请参见 经验证的硬件设计。
文件系统服务
BeeGFS文件系统包括以下主要服务:
-
*管理服务。*注册并监控所有其他服务。
-
*存储服务。*存储称为数据区块文件的分布式用户文件内容。
-
*元数据服务。*跟踪文件系统布局、目录、文件属性等。
-
*客户端服务。*挂载文件系统以访问存储的数据。
下图显示了NetApp E系列系统中使用的BeeGFS解决方案 组件和关系。
作为一个并行文件系统、BeeGFS会将其文件条带化到多个服务器节点上、以最大限度地提高读/写性能和可扩展性。服务器节点协同工作、可提供一个文件系统、其他服务器节点(通常称为_clients_)可以同时挂载和访问该文件系统。这些客户端可以查看和使用分布式文件系统、类似于NTFS、XFS或ext4等本地文件系统。
这四项主要服务在广泛支持的Linux分发版上运行、并通过任何支持TCP/IP或RDMA的网络进行通信、包括InfiniBand (IB)、OMNI-Path (OPA)和基于融合以太网的RDMA (RoCE)。BeeGFS服务器服务(管理、存储和元数据)是用户空间守护进程、而客户端是原生 内核模块(无修补)。所有组件均可在不重新启动的情况下安装或更新、您可以在同一节点上运行任何服务组合。
HA架构
NetApp上的BeeGFS通过创建与NetApp硬件完全集成的解决方案 来扩展BeeGFS企业版的功能、从而实现共享磁盘高可用性(HA)架构。
虽然BeeGFS社区版可以免费使用、但企业版要求从NetApp等合作伙伴购买专业支持订阅合同。企业版支持使用多项附加功能、包括故障恢复能力、配额强制实施和存储池。 |
下图对无共享和共享磁盘HA架构进行了比较。
有关详细信息,请参见 "宣布NetApp支持的BeeGFS高可用性"。
已验证节点
经验证的硬件设计
该解决方案的组件(如下图所示)使用经过验证的文件节点服务器作为BeeGFS文件层、并使用两个EF600存储系统作为块层。
NetApp解决方案 上的BeeGFS可跨部署中的所有组件运行。部署的第一个组件必须运行BeeGFS管理、元数据和存储服务(称为基础组件)。所有后续组件均可通过软件进行配置、以扩展元数据和存储服务、或者专门提供存储服务。通过这种模块化方法、可以根据工作负载的需求扩展文件系统、同时使用相同的底层硬件平台和组件设计。
最多可以部署五个组件、以构成一个独立的Linux HA集群。这样可以优化PacMaker的资源管理、并保持与Corosync的高效同步。将一个或多个独立BeeGFS HA集群组合在一起、以创建一个BeeGFS文件系统、此文件系统可作为一个存储命名空间供客户端访问。在硬件方面、一个42U机架最多可容纳五个组件、并可为存储/数据网络配备两个1U InfiniBand交换机。有关可视化表示、请参见下图。
要在故障转移集群中建立仲裁、至少需要两个组件。双节点集群存在一些限制、可能会阻止成功进行故障转移。您可以通过将第三个设备整合为Tieb破碎 机来配置双节点集群;但是、本文档不会介绍这种设计。 |
Ansible
NetApp上的BeeGFS是使用Ansible自动化交付和部署的、Ansible自动化托管在GitHub和Ansible GALAXY上(BeeGFS集合可从获取 "Ansible Galax河" 和 "NetApp的E系列GitHub")。虽然Ansible主要是使用用于组装BeeGFS组件的硬件进行测试的、但您可以将其配置为使用受支持的Linux版本在几乎任何基于x86的服务器上运行。
有关详细信息,请参见 "使用E系列存储部署BeeGFS"。