lustre客户端实现的答疑解惑

用户4700054

发布于 2022-08-17 12:45:35

7530

发布于 2022-08-17 12:45:35

如何理解lustre客户端中的device?

lustre客户端有client stack中的device.mount时候从mgs获取到llog解析出来的 cl_device.客户端的device stack可以理解为一系列mds/mgs/oss的抽象抽象以及客户端内部IO处理的接口抽象.一个文件从客户端进入，每一层会都有自己的私有object,于此同时每一层的对象针对当前层处理object的device，当前层处理完毕，通过object中的header信息，找到下一层，接着处理直到完成网络传输到后端的oss或者mds.

// cl_device包含了lu_device;lu_device包含了obd_device
struct cl_device -> struct lu_device ->struct obd_device

lustre客户端有哪些object?

lustre客户端stack中，一个文件处理需要vvp_object、lov_object、lovsub_object、osc_object。每一层的对象都会包含通用的对象层cl_object.vvp_object是vfs-vm-posix层的对象，这个包含了操作文件的inode和cl_object的客户端通用对象;lov_object是为了处理来自vvp_object的封装的数据，其中也包含了cl_object，这一层是逻辑对象层，比如文件被stripe后，在lov_object会包含多个sripe的对象，这些对象封装成对象lovsub_object,每一个lovsub_object对应一个osc_object对象。最后osc_object通过自己这一层的device的接口层，数据到mds或者oss.

// 最顶层的client object.
struct vvp_object {
	// header指向下一层的操作的函数指针
	struct cl_object_header vob_header;
	// VVP层的cl_object对象
	struct cl_object        vob_cl;
	// 文件操作的inode
	struct inode           *vob_inode;
};

// 第二层的lov_object处理层
struct lov_object {
	struct cl_object	lo_cl;
	struct lov_stripe_md  *lo_lsm;
	union lov_layout_state {
		struct lov_layout_composite {
			struct lov_layout_entry *lo_entries;
		} composite;
	} u;

};

// 第三层的lovsub_object处理层
struct lovsub_object {
        struct cl_object_header lso_header;
        struct cl_object        lso_cl;
        struct lov_object      *lso_super;
        int                     lso_index;
};

// 第四层osc_object处理层
struct osc_object {
	struct cl_object	oo_cl;
	struct cl_io		oo_debug_io;
	const struct osc_object_operations *oo_obj_ops;
};

lustre客户端中object和device是什么关系?

客户端object和device关系概览

vvp_object内部关系

lov_object和lovsub_object内部关系

osc_object内部关系

客户端从mgs如何获取配置信息？

客户端mount时候会初始化客户端的超级块，然后根据mount的options信息连接到MGS,紧接着处理启动MGC模块，MGC模块开始处理来自MGS的lustre log,分别获取CONFIGS/mountdata、CONFIGS/nodemap、CONFIGS/params、CONFIGS/{fsname}-client配置，最后进行处理。{fsname}-client是存储了当前客户端的device stack的配置(lov、lmv、osc、mdc);nodemap存储了当前每个节点的映射关系；params存储了集群参数;mountdata存储了客户端的挂载信息。CONFIGS/nodemapCONFIGS/paramsCONFIGS/{fsname}-client{fsname}-clientnodemapparamsmountdata

1.lu stre_fill_super : mount 加载时进行
初始化 2.lu stre_start_mgc :连接mgs 
3.ll _fill_super :初始化超级块
4.lu stre_process_log : mgs的日志
5. obd_process_config :当前mgc挂处理mgs的日志
6. mgc_process_config :根据mgs的初始化日志客户端的堆栈

enum  mgs_cfg_type { 
	// 集群的配置
	MGS_CFG_T_CONFIG	 =  0 , 
	MGS_CFG_T_SPTLRPC	 =  1 , 
	MGS_CFG_T_RECOVER	 =  2 , 
	// 集群的参数
	MGS_CFG_T_PARAMS	 =  3 , 
	// 集群的节点	图
	GS_CFG_T_NODEMAP	 =  , 	MGS_CFG_T_T_CFG	 = 5 , MGSMAX_CFG_ };

客户端获取日志时间定了日志类型，具体参照如下
函数的执行流程如下

客户端如何知道集群的参数变动或者节点变动？

目前客户端是通过mgc模块实时watch整个集群的变动，在mount时候会进行mgc_setup设置,会启动一个内核线程间断和MGS寻轮通信，获取当前集群的变更，然后本地客户端就知道当前集群的变动。如果参数或者节点有变动，所有的客户端是知道的，如果添加新的ost，mgc会获取mgs log进行解析，重新加载。

// mgc_setup启动内核线程来做寻轮
static int mgc_setup(struct obd_device *obd, struct lustre_cfg *lcfg)
{
	task = kthread_run(mgc_requeue_thread, NULL, "ll_cfg_requeue");
}
// 内核线程的任务逻辑
static int mgc_requeue_thread(void *data)
{
	while (!(rq_state & RQ_STOP)) {
		struct config_llog_data *cld, *cld_prev;
		to = cfs_time_seconds(MGC_TIMEOUT_MIN_SECONDS * 100 + rand);
		/* rand is centi-seconds */
		wait_event_idle_timeout(rq_waitq,
					rq_state & (RQ_STOP | RQ_PRECLEANUP),
					to/100);
		do_requeue(cld);
	}
}

客户端获取到{fsname}-client哪些内容？

dump相关的mgs的配置信息,客户端获取到{fsname}-client数据后，解析日志启动对应的obd(lov/lmv/osc/mdc/mgc)

$ debugfs -c -R 'dump CONFIGS/bigfs-client /tmp/bigfs-client' /dev/sdb 
$ llog_reader  /tmp/bigfs-client  > ~/bigfs_client.info
$ cat bigfs_client.info  |grep -v marker |grep setup
#03 (168)lov_setup 0:bigfs-clilov  1:(struct lov_desc)
#07 (168)lov_setup 0:bigfs-clilmv  1:(struct lov_desc)
#12 (144)setup     0:bigfs-MDT0000-mdc  1:bigfs-MDT0000_UUID  2:10.211.55.12@tcp  
#21 (144)setup     0:bigfs-OST0000-osc  1:bigfs-OST0000_UUID  2:10.211.55.12@tcp  
#27 (144)setup     0:bigfs-OST0001-osc  1:bigfs-OST0001_UUID  2:10.211.55.12@tcp

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2022-01-12，如有侵权请联系 cloudcommunity@tencent.com 删除

编程算法