本文详细介绍了如何为CephFS部署基于NFS-Ganesha的高可用集群，包括NFS-Ganesha的配置、gracedb的管理、HAProxy和Keepalived的设置。在测试中，当服务端断网超过五分钟，客户端被Ceph超时驱逐，通过调整Ceph配置避免了客户端加入黑名单，确保了服务的快速恢复和稳定性。
涉及系统较多，概念介绍内容稍多，使用的话可以直接看部署实践，通过实践来理解各种系统和概念
1. 概述
NFS是linux操作系统共享文件系统使用广泛的协议，也是各种共享文件产品的标准功能，客户端安装简单、使用简单。CephFS相对来说要安装CephFS客户端，添加客户端配置等，对于用户来说NFS更方便使用。
本文旨在说明如何为CEPHFS部署一个高可用的NFS网关集群
- 为什么要给NFS做集群
- nfs是个有状态服务，有状态服务高可用必须要保持状态的一致性，状态为
- Open files
- File locks
- …
- nfs是个有状态服务，有状态服务高可用必须要保持状态的一致性，状态为
- 当前有什么比较成熟的技术方案
- rook是当前唯一可以找到的资料比较齐全的CephFS导出NFS的实现
- 通过K8S的 ing svc deployment来保证服务的高可用
- 通过ceph集群来存储文件系统的状态
- rook是当前唯一可以找到的资料比较齐全的CephFS导出NFS的实现
- 已有的技术方案有什么技术优缺点
- 优点: 社区支持
- 缺点: 只能通过容器化方式ROOK来部署，生产Ceph上容器是一件极具挑战的事。不过nfs集群使用容器，ceph集群使用进程也是一种方式，但是这样增加了一些交付难度。
2. 术语
-
nfs1: 是一个有状态服务，客户端服务端之间维护如下信息
- Open files
- File locks
-
nfs服务属性2:
- Minimum supported version（支持的最低版本）
- Grace period（宽限期) 定义从计划外中断重新引导设备（从 15 秒到 600 秒）后所有客户机必须在多少秒内恢复锁定状态。该属性只影响 NFSv4.0 和 NFSv4.1 客户机（NFSv3 是无状态协议，因此没有要恢复的状态）。在此期间内，NFS 服务只处理旧锁定状态的回收。在宽限期结束之前，不会处理对服务的其他请求。默认宽限期为 90 秒。减小宽限期将使得 NFS 客户机在服务器重新引导之后能够更快地恢复操作，但也会增加客户机无法恢复其所有锁定状态的可能性。
- Enable NFSv4 delegation（启用 NFSv4 委托） 选择此属性将允许客户机在本地缓存文件且无需联系服务器即可进行修改。此选项默认情况下启用且通常可提高性能，但在极少的情况下可能会引起问题。如果要禁用此设置，只能在对特定工作负荷进行仔细的性能测量并验证了这样设置具有相当的性能优势后进行。此选项只影响 NFSv4.0 和 NFSv4.1 挂载。
- Mount visibility（挂载可见性 此属性允许您限制有关 NFS 客户机共享资源访问列表和远程挂载等信息的可用性。完全允许完全访问。受限的限制访问，比如客户机仅能查看允许其访问的共享资源。客户机看不到在服务器上定义的共享资源或服务器中其他客户机完成的远程挂载的访问列表。默认情况下，此属性设置为 “Full”（完全）。
- Maximum supported version（支持的最高版本）
- Maximum # of server threads（最大服务器线程数） 定义并发 NFS 请求的最大数目（从 20 到 1000）。这至少应当涵盖您预期的并发 NFS 客户机的数目。默认值是 500。
3. nfs-ganesha
3.1. 介绍
nfs-ganesha3: 是一个nfs服务器，支持将不同的文件系统导通过 FSAL(File System Abstraction Layer) 导出为nfs , 支持以下文件系统导出为NFS。
- cephfs
- Gluster
- GPFS
- VFS
- XFS LUSTER
- RadosGW
3.2. 架构
3.2.1. 总体架构图
- 社区的架构图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-26YBcvXc-1634473847273)(https://raw.githubusercontent.com/wiki/nfs-ganesha/nfs-ganesha/images/nfs-arch.png)] - 更加详细的IBM的架构图4
3.2.2. 架构说明
要使用nfs-ganesha重点关注以下几点
nfs-ganesha作为各种分布式文件系统的客户端，客户端使用文件系统时需要将目录结构(Dentry)和本地文件系统跟后端存储介质/远程文件系统的映射(inode)做缓存5
- 需要导出为nfs的各种分布式文件系统
- MDCACHE: 后端文件系统的元数据缓存(Dentry Innode)
- FSAL: 需要到处的文件系统抽象层，统一了后端不同文件系统的api
- NFS: 用户使用各种分布式存储导出的nfs服务
- LOG: nfs-ganesha服务日志
- 默认日志路径:
/var/log/ganesha/ganesha.log - 其他log配置
- 默认日志路径:
3.2.3. genesha-rados-cluster设计
这里是Ceph的专场，设计文档源自官方文档的翻译6
3.2.3.1. 客户端恢复(单体情况)
NFSv4是基于租期的协议, 客户端与服务端建立连接之后，必须定期更新足月以维持文件系统状态(open files, locks, delegations or layouts)
当一个nfs服务重启后所有的状态丢失。当服务重新上线，客户端会检测到服务已启动，从服务端获取到上一次的连接状态恢复连接。
3.2.3.2. 宽限期(单体情况)
grace period, 简言之，客户端和服务端在连接中断后恢复上一次的连接状态时，如果超时了则恢复超时(宽限期)则重新建立连接，在恢复过程中，客户端被禁获取新的状态，只允许回收状态。
3.2.3.3. Reboot Epochs
服务版本
- R Recovery
- N Normal
版本状态
- C 当前版本，体现在grace db dump输出上为 cur
- R 非0值表示宽限期的有效时间，0表示结束，体现在grace db dump输出上为 rec
3.2.3.4. gracedb
有状态的数据记录在数据库，rados-cluster的recovery信息存储在rados omap，通过 ganesha-rados-grace7命令行可以操作数据，例如将节点加入集群，将节点踢出集群，加入集群之后节点有两个状态
- N(NEED) 该节点是否有需要recovery的的客户端
- E(ENFORCING) 强制执行宽限期
3.2.3.5. 集群
上面的客户端恢复、宽限期、gracedb说明了单体服务的恢复原理和状态存储，对于集群只是将单体服务部署多个，状态保持一致
ganesha集群场景: 部署多个ganesha服务，服务端通过VIP或者DNS等方式访问其中一个，如果正在访问的ganesha服务挂了，客户端换到另一个ganesha服务进行访问(需要注意的是上次访问的状态数据也同步到了集群的其他节点的数据库中)，新的访问连接恢复了原来的状态，如果恢复不了则数据库删除原来的状态进行重建连接。
3.3. 高可用集群实现
- 无状态部分: 部署多个ganesha服务，通过keepalive+haproxy进行高可用负载
- 有状态部分: 状态数据通过gracedb管理，存储在ceph rados对象的omap中
以上，架构确定了，开始部署
4. 部署
4.1. 环境说明
| 组件 | 版本 | 备注 |
|---|---|---|
| 操作系统 | CentOS Linux release 7.8.2003 (Cor |
最低0.47元/天 解锁文章
扫一扫
651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
