本文共 3314 字,大约阅读时间需要 11 分钟。
第一部分提供了了背景信息去帮助你理解Lustre文件系统的架构和这些主要部件是如何彼此配合的。其中你将发现一下信息:
Lustre文件系统的架构
Lustre文件系统的网络
Lustre文件系统的故障处理
本章描述了Lustre的架构和Lustre文件系统的特性。它包含了以下几个小节:
1.1:什么是Lustre文件系统
1.2:Lustre的组成
1.3:Lustre文件系统存储和I/O
Lustre架构就是集群的一个存储架构。Lustre架构的核心组成部分就是Lustre文件系统,依赖于Linux操作系统,提供了一个服从于标准的UNIX文件系统接口的POSIX。
Lustre存储架构被用于很多不同种类的集群。它因为广泛的使用在最大的高性能计算机(HPC)而被熟知,很多的HPC使用Lustre文件系统作为全局的文件系统,服务于许多的集群。
Lustre文件系统对于需要减少部署许多分离式系统的集群具有提高生产力和性能的能力。通过避免计算机群之间拷贝数据,存储管理也被简化了。除了能够聚集很多服务器的存储性能之外,也能够聚集众多服务器的I/O吞吐能力。而且通过动态的增加服务器也可以很容易的增加吞吐和容量。
当Lustre文件系统运行在众多的工作环境中时,它并不一定就是最好的选择。当超过单个系统所能提供的容量后,它才是最适应与用户的。尽管在某些情况下,对于单个服务器来说Lustre文件系统可能要比其他系统表现的更好,由于其强锁和数据一致性。
一个Lustre文件系统暂时并不是特别适用于点对点模式,客户端与服务端运行在相同的节点上,每个分享了一小部分的存储,由于对于Lustre软件级别反响的数据缺失。在这种使用环境下,如果一个客户端或着服务端失败了,那么那个节点上的数据将会不可读取知道节点回复。
Lustre文件系统可以运行在多种类的供应商内核中。详细信息,查看Lustre Test Matrix 8.1 章节, “准备安装Lustre软件”。
一个Lustre的安装可以随着客户端节点数量,磁盘存储和通信带宽进行规模的增减。规模和性能依赖于可用的磁盘和网络带宽以及系统中服务器的处理能力。Lustre文件系统可以被部署在各种各样的配置中,这些配置远远超过我们在生产系统中观察到的规模和性能。
其他的特性包括:
Lustre 2.4
在lustre软件版本2.4以后,也可以使用ZFS文件系统的支持MDT,OST,和MGS存储。这允许Lustre去改变可扩展性和对于个体存储ZFS的数据完整性。
符合POSIX标准
高性能异构网络
高可用性
安全性
访问控制列表,扩展特性
互操作性
基于目标的架构
Byte-granular file and fine-grained metadata locking
磁盘配额
容量可扩充
可控的文件布局
网络数据完整保护
MPI I/O
NFS and CIFS export
灾难恢复工具
性能监控
开源
Lustre软件的安装包括了一个管理服务器(MGS)和一个或者更多的与Lustre网络(LNet)互联的Lustre文件系统。
Lustre文件系统组成的基本配置如图1.1所示:
MGS中存储着一个集群中Lustre文件系统的配置信息,并且把这个信息提供给其他的Lustre组成部分。每一个Lustre目标都会与MGS联通提供信息,而客户端与MGS联通去取回信息。
MGS有它自己的存储空间将会更好,以便于它能够独立地被管理。而且MGS也能和MDS协同分享存储空间,正如图1.1所示。
每一个Lustre文件系统由以下几个部分组成:
元数据服务器(MDS):MDS产生元数据存储在一个或者多个有可用的Lustre客户端的MDT中,每一个MDS管理着Lustre文进系统中文件的名字和目录和提供网络请求处理一个或者多个本地的MDT。
元数据目标(MDT):对于2.3及其更早的版本,每一个文件系统都有一个MDT。MDT存储着元数据(比如文件名、目录、权限和文件布局)在依赖于MDS的存储上。每一个文件系统有一个MDT。共享存储目标的MDT对于多路的MDS是可用的,尽管同时只有一个可用。如果一个正在运行的MDS死掉了,那么一个备用的MDS就会服务与MDT,让他对于客户端是可用的。这被引申为MDS故障处理。
对象存储服务器(OSS):OSS提供文件I/O服务和网络请求处理一个或多个地方的OST。通常,两个到八个的OST之间的OSS服务器,每个高达16 TB。一个典型的配置在专用节点的MDT,两个或两个以上OST在每个OSS节点,并在每个计算节点的大量客户端。
对象存储目标(OST):用户文件数据存储在一个或多个对象中,每一个对象位于Lustre文件系统中的一个独立的OST上。每个文件的对象数是由用户配置的,可以调整以优化给定工作负载的性能。
Lustre客户端:Lustre客户端是计算、可视化或桌面节点,运行着客户机软件,允许他们安装Lustre文件系统。
表1.2 Lustre文件系统组件的存储和硬件要求
Required attached storage | Desirable hardware characteristics |
---|---|
MDSs | 1-2% of file system capacity |
OSSs | 1-128 TB per OST, 1-8 OSTs per OSS |
Clients | No local storage needed |
Lustre网络(LNET)是一个自定义的网络API,提供通讯基础设施处理Lustre文件系统服务器和客户端的元数据和文件I/O数据。关于LNet的更多信息,参见2章,了解Lustre网络(LNET)。
在规模上,Lustre文件系统的集群可以包括成千上万的客户端和数百的OSS(见图1.2,“Lustre集群规模”。多个类型的网络可用于Lustre集群中。OSS之间的共享存储能够拥有故障服务能力。有关OSS故障转移的详细信息,请参阅第3章,理解Lustre文件系统中的故障服务。
在Lustre软件版本2.0,Lustre文件标识符(FID)被引入代替UNIX inode编号为识别文件或对象。一个FID就是一个128位的标识符包含一个唯一的64位序列号,一个32位的对象标识(OID),和一个32位的版本号。序列号在在文件系统(OST和MDTs)的所有的Lustre目标是独一无二的。这种变化使多路MDTs未来的支持(推出Lustre软件版本2.4)和ZFS(推出Lustre软件版本2.4)。
还介绍了在2.0版是一个ldiskfs特征命名的FID-in-dirent(也被称为dirdata),FID存储在父目录的文件名的一部分。通过减少磁盘I/O,这个特性显著提高了ls命令执行的性能。文件创建时这个FID-in-dirent就立刻生成了。
Note
FID-in-dirent特性不是向后兼容版本1.8 ldiskfs磁盘格式。因此,当从版本1.8升级到版本2.x时,自动启用FID-in-dirent特性。从版本1.8升级到版本2.0到2.3,FID-in-dirent可以手动启用只对新文件的起影响。
有关从Lustre软件版本1.8和使FID-in-dirent现有文件升级的更多信息,参见17章,Lustre文件系统升级 ,第16章, “Lustre文件系统升级” 。
转载地址:http://lgarb.baihongyu.com/