本文是在阅读Introduction to Lustre* Architecture的Lustre File System – Clients时的笔记。
Lustre客户端部署在客户的计算节点上,工作时不占用本地的硬盘。
- 不使用本地硬盘作为缓存或者后备空间。
- 对存储系统的访问均通过网络。
Lustre客户端作为Linux内核的模块,工作在内核态,有如下特点:
- 通过提供硬盘的挂载点来提供访问服务。
- 客户应用的访问方法兼容POSIX规范,保证客户端无需修改、适配即可访问。
使用Lustre客户端时,有如下注意事项:
- 对开发、测试、运维团队的技能有一定的要求,需要对内核有相应的了解。
- 开发、调试、定位问题,相对比较困难。
- 故障后的恢复手段比较单一,可能很多问题都需要重启系统,此时将中断业务。
Lustre客户端包括如下组件:
- MGC即Management Client,负责与MGS通信。MGC部署在MGS节点和客户端节点。
- MDC即Metadata Client,负责与MDS通信。MDC部署在客户端节点。
- OSC即Object Storage Client,负责与OST通信。OSC部署在MDS和客户端节点。
LNet router即Lustre Network Routers,负责桥接不同网络协议,纯软件解决方案。
说起存储系统的客户端,可以联想到很多,比如:
- 客户端的体量
- 胖客户端
- 瘦客户端
- 无客户端
- 客户端与客户应用间通信的方式
- POSIX
- NFS
- CIFS
- S3
- SDK
- 客户端与存储系统间通信的方式
- NFS
- CIFS
- S3
- 私有
- 集成方式
- 作为SDK,内置在客户应用内部。
- 独立进程,与客户应用共节点部署。
- 1个进程对应多个客户应用。
- 1个进程对应1个客户应用。
- 独立进程,单独节点部署。
- 占用的资源
- CPU
- 内存
- 硬盘
- 网络
- 缓存策略
- 缓存的内容
- 元数据
- 数据
- 缓存的可用范围
- 进程内可用
- 节点内可用
- 节点间可用
- 资源消耗
- 性能
- 一致性
- 老化算法
- LRU
- 老化时机
- 访问时老化
- 定时,即启用定时任务,定期检查缓存占用的空间
- 定量,实时监控占用空间,超出阈值即老化
- 缓存的位置
- 内存
- 硬盘
- 缓存的内容
- 外部依赖
- 网络
- 集成的成本
- 学习成本
- 改造现有应用的成本
- 版本管理
- 升级成本
- 运维
- 故障
- 业务恢复手段
- 业务中断时长
- 业务中断次数
- 日常维护
- 版本升级
- 版本管理
- 停机时长
- 业务中断时长
- 故障
依据上述分析,对Lustre客户端总结如下:
- Lustre客户端可以认为是胖客户端。
- Lustre客户端与客户的应用同机部署,需要消耗计算节点的资源,占用资源的规格,与性能的关系,需要后续分析,掌握评估方法。
- 在客户计算节点上,安装并加载Lustre的内核模块,挂载硬盘访问点,客户的应用通过POSIX的文件API,即可访问Lustre存储集群。
- Lustre客户端和Lustre存储集群之间使用私有的协议交互数据。
- 客户的应用通过Lustre客户端访问Lustre存储集群时,所有的操作均直接通过网络操作完成,不占用本地存储的空间。
- Lustre客户端是否使用缓存、以及缓存的使用方式,需要再深入代码来研究、确认。
- 考虑到对客户应用而言,通过Lustre客户端访问Lustre存储集群,和访问本地挂载的盘或者分区类似,因此不涉及学习成本及应用的改造成本。
- 由于Lustre客户端工作在内核态,因此在日常运维、问题定位、版本管理等方面,存在一定的工作量。
- 当遇到Lustre客户端相关的故障时,可能需要中断业务、重新挂载、重启节点等才能规避,因此需要评估业务中断时长对客户的影响。