天翼云弹性文件服务（CT-SFS，Scalable File Service）提供安全、可靠、可扩展、高性能的共享文件存储服务，满足云上多台云主机的共享访问需求。下图所示为CT-SFS当前架构图，其中最下层为分布式存储集群，提供统一命名空间的分布式文件系统。CT-SFS的管理控制及容灾、负载均衡等功能由分布式文件网关提供，文件网关上运行网络文件系统服务端，将分布式文件系统存储空间提供给客户端挂载使用，一个分布式网关可以提供多个共享文件系统。
1. 监控需求描述
分布式文件网关各节点上运行网络文件系统服务端，为满足产品监控需求，需要在各节点提供按文件系统粒度监控性能数据的能力，主要包括读写iops、带宽、时延等指标，本文描述了该需求当前针对nfs协议共享的按文件系统粒度监控实现方案。
2. 方案调研分析
CT-SFS当前nfs服务端使用的操作系统内核原生实现，需要在已有架构上考虑性能监控能力增强方案。下表总结了前期各方案调研结果，包括nfs配套工具、块层监控工具iostat等，最终我们选取了基于当前流行的eBPF框架增强开发专用监控工具的方案。
|
备选方案 |
原理 |
是否满足需求 |
工作量 |
|
nfs配套工具nfsiostat、nfsstat等 |
操作系统自带nfs原生工具 |
否，nfsiostat在客户端监控，且指标不全。nfsstat可以在服务端监控，但是统计的nfs命令计数 |
N/A |
|
iostat |
操作系统原生块层性能监控 |
部分满足，块层的统计与文件系统层不完全一致，且不适用于后端使用分布式文件系统场景 |
N/A |
|
基于eBPF定制 |
io函数hook，统计性能数据，其中按文件系统粒度监控的需求通过关联函数中的nfs句柄实现，具体见后文2.3节说明 |
是 |
较小，eBPF擅长于观测内核数据，且提供了数据统计框架，且eBPF在内核安全性方面也有一定保证。 |
|
nfs服务端开发 |
定制开发服务端代码，增加性能统计 |
是 |
大，需要较多修改nfs服务端代码，且新实现数据统计框架。如果想重用内核现有性能统计设施，需要开发者对linux内核sunrpc框架、nfs等模块代码有足够熟悉。 |
2.1. nfs介绍
NFS是Network File System的缩写，即网络文件系统，它的主要功能是通过网络（一般是局域网）让不同的主机系统之间可以共享文件或目录。NFS客户端（一般为应用服务器，例如web）可以通过挂载（mount）的方式将NFS服务端共享的数据目录挂载到NFS客户端本地系统中（就是某一个挂载点下）。从NFS客户端的机器本地看，NFS服务端共享的目录就好像是客户自己的磁盘分区或者目录一样，而实际上确是远端的NFS服务端的目录。
从1985年推出至今，nfs共发布了3个版本：NFSv2、NFSv3、NFSv4，NFSv4包含两个次版本NFSv4.0和NFSv4.1。相比NFSv3，NFSv4发生了比较大的变化，最大的变化是NFSv4有状态了。NFSv2和NFSv3都是无状态协议，服务端不需要维护客户端的状态信息。
关于nfs的历史网上资料很多，有兴趣的读者可以自行了解。NFSv3协议的官方定义是rfc1813（https://www.rfc-editor.org/info/rfc1813），后文深入代码使用nfs读写请求参数，以及句柄特性，涉及协议格式相关的原始定义都可以在上述文档查询到。
2.2. ebpf介绍
Linux 内核一直是实现监控/可观测性、网络和安全功能的理想地方。不过很多情况下这并非易事，因为这些工作需要修改内核源码或加载内核模块，最终实现形式是在已有的层层抽象之上叠加新的抽象。eBPF 是一项革命性技术，它能在内核中运行沙箱程序（sandbox programs），而无需修改内核源码或者加载内核模块。将 Linux 内核变成可编程之后，就能基于现有的（而非增加新的）抽象层来打造更加智能、功能更加丰富的基础设施软件，而不会增加系统的复杂度，也不会牺牲执行效率和安全性。
eBPF 催生了一种全新的软件开发方式。基于这种方式，我们不仅能对内核行为进行编程，甚至还能编写跨多个子系统的处理逻辑，而传统上这些子系统是完全独立、无法用一套逻辑来处理的。eBPF当前正在性能分析、安全分析、网络分析、观测监控等领域大展拳脚。
关于eBPF更进一步的介绍及其大量的应用项目场景，可以参考其官方文档https://ebpf.io/zh-cn/，另一个比较深入介绍eBPF的网站是 https://www.ebpf.top/。
2.3. 性能监控具体方案
2.3.1. eBPF Hook nfs服务端函数
使用eBPF框架在服务端Hook nfs写函数nfsd3_proc_write，nfsv3共享文件系统的所有写请求都会经过该函数处理，函数原型如下。
/*
* Write data to a file
*/
static __be32
nfsd3_proc_write(struct svc_rqst *rqstp)
{
struct nfsd3_writeargs *argp = rqstp->rq_argp;
struct nfsd3_writeres *resp = rqstp->rq_resp;
__be32 nfserr;
unsigned long cnt = argp->len;其入参数为请求处理上下文，其中比较重要信息是nfsd3_writeargs结构，包括了写请求对应的文件句柄、文件偏移、以及待写入数据等信息。
struct nfsd3_writeargs {
svc_fh fh;
__u64 offset;
__u32 count;
int stable;
__u32 len;
struct kvec first;
};通过在Hook回调函数中统计调用次数得到iops、累加写的数据长度得到带宽，同样Hook该函数返回事件，并统计时差得到请求处理时延。
通常按秒为间隔统计以上性能数据，bBPF框架为实现以上功能提供了Hook实现、数据map、用户态内核态通信等基础套件，同时bBPF通过虚拟机环境运行、字节码静态分析等功能保证新增代码不影响系统稳定性。
对于读性能统计，对等Hook nfsd3_proc_read函数即可实现。
/*
* Read a portion of a file.
*/
static __be32
nfsd3_proc_read(struct svc_rqst *rqstp)
{
struct nfsd3_readargs *argp = rqstp->rq_argp;
struct nfsd3_readres *resp = rqstp->rq_resp;
__be32 nfserr;
u32 max_blocksize = svc_max_payload(rqstp);
unsigned long cnt = min(argp->count, max_blocksize);
struct nfsd3_readargs {
struct svc_fh fh;
__u64 offset;
__u32 count;
int vlen;
};2.3.2. 文件句柄对应文件系统
以上两个函数传入参数类型为struct svc_rqst型指针，写请求参数或读请求参数中都包含了请求待操作的nfs句柄，nfs句柄标识了io请求对应的文件，该句柄与文件归属的文件系统存在一定对应关系，从而可以将当前io统计到对应文件系统下，实现最初按文件系统统计性能数据的需求。下图示意从该参数获取nfs文件句柄的结构关系。
fh_base在nfsv3版本的一个示例为
对应的挂载根句柄在客户端mount请求时生成。
可见文件系统下的文件与挂载根目录，句柄组成部分有明显对应关系。
分析nfs服务端生成句柄的代码，关键点如下图，在文件nfsfh.h中，构造句柄的方式在nfs共享目录为文件系统根目录时或子目录时，句柄中都会固定携带文件系统fsid，区别在于，子目录情况下，在fsid之前增加了8字节的inode号。
其中用到的fsid是由用户态nfs-utils包中的mount进程代码中生成的（utils/mountd/cache.c）。
如上分析，监控工具可以先根据mountd进程同样原理计算得到共享目录将要使用的nfs句柄的uuid内容，另一方面，Hook回调函数处理io请求时，从请求句柄中截取uuid部分，与监控工具前期计算内容对比即可将处理的请求归类到特定共享目录。
3. 监控效果
下图为最终性能监控工具运行效果，客户端采用sync挂载方式以消除系统缓存影响，可以看到iops和带宽统计数据与客户端vdbench输出基本保持一致，时延数据vdbench统计的为包含网络时延，工具统计的只是服务端文件系统时延。
下图为文件网关上有多个共享文件系统时的监控效果。
4. 总结
本文先介绍了天翼云弹性文件架构及其在网络文件系统服务端按文件系统粒度的性能监控需求，接着详细介绍了该需求当前实现的基于eBPF hook统计数据，并根据请求句柄与文件系统对应，以实现文件系统粒度性能监控的方案。
未来，天翼云将继续坚持自主创新，发挥自身技术优势，持续提升创新能力与核心竞争力，为自主可控、可靠高效的云计算基础架构添砖加瓦，为国家信息技术产业的发展提供坚实的技术保障。
