开源系统运营优化
分享开源系统架构、运营实践、源码分析、解决的问题
yueyingshaqiu01
分布式存储架构师
展开
-
TiKV集群部署
注:如果/home/tikv/.ssh/目录下有不正确的id_rsa文件,会导致鉴权失败,请删除~/.ssh/id_rsa*;将中控机.ssh/id_rsa.pub内容追加到各部署机的/home/tikv/.ssh/authorized_keys文件末尾,没有.ssh目录则先手动创建.ssh目录。注:如果要输入密码,统一输入tikv(保证统一),其它现象直接默认,如果密码输错了,可以用sudo userdel tikv重来。注:如果这一步没有成功,可以重新执行下,确保没有Fail,才能执行下一步。原创 2024-07-19 14:12:05 · 378 阅读 · 0 评论 -
juicefs部署实践
注:如果是CephRados作为对象存储后端,则需要将ceph.conf和ceph.client.admin.keyring拷贝到/etc/ceph/目录下,然后执行format, juicefs.ceph format --storage ceph --bucket ceph://juicefs_data --access-key ceph --secret-key client.admin。如:juicefs format --storage s3 --bucket。注:如果是研测环境,url换成"原创 2024-07-19 14:09:43 · 832 阅读 · 0 评论 -
juicefs 一致性
内核元数据缓存时间受到mount参数控制(只有过期失效),open时默认会绕过内核的文件属性缓存,到达juicefs客户端,如果--opem-cache为false(默认是false),则会绕过客户端内存的文件属性缓存,去元数据服务器同步文件属性。对于跨chunk的不同机器client的并发写,juicefs本身是不提供原子保证的,需应用自己调用SetLk接口来实现互斥。对于同一个chunk不可机器client的并发写,后写的会覆盖之前写的;元数据更新是事务更新,数据更新是写时复制(不覆盖)原创 2024-07-19 14:07:11 · 193 阅读 · 0 评论 -
ceph log内容解析
dout和ldout类似,也是带前缀的dout_impl,只有个别模块有使用,如src/mds/MDBalancer.cc中。分别表示 时间戳 线程id 日志等级 子模块 内容实体。定义在src/common/dout.h中。定义在src/log/entry.h中。ldout是带前缀的dout_impl。每条log都是由一个Entry构成。如osd的一条log。原创 2024-07-19 14:03:32 · 396 阅读 · 0 评论 -
ceph osd写流程
原创 2024-07-19 13:54:24 · 257 阅读 · 0 评论 -
ceph进程网卡绑定逻辑
->pick_addresses() // 会读取"cluster_network_interface"和"public_network_interface"这两个配置项来过滤ip。main() //如osd进程,是ceph_osd.cc文件的main函数;mon进程,是ceph_mon.cc文件的main函数。原创 2024-07-19 13:53:23 · 528 阅读 · 0 评论 -
ceph条带化原理
数据按照ChunkSize进行布局,不满一个StripeWidth的,后面的StripeUnit进行padding (不满一个条带的按照一个条带对齐,牺牲空间换取性能)原创 2024-07-19 13:52:47 · 97 阅读 · 0 评论 -
cephfs journal模块
fs元数据更新时,MDS执行journal_and_reply,首先封装成log_event,通过submit_mdlog_entry提交到pending_events中,然后submit_thread将journal flush到metadata pool的rados object(200.XXXXXXXX)中,后续在trime_mdlog时,将dirty inode写到metadata pool的rados object(inodeNum.XXXXXXXX)中。原创 2024-07-19 13:51:51 · 118 阅读 · 0 评论 -
cephrbd常用命令
拷贝ceph.client.{username}.keyring到/etc/ceph/目录。applicationname是rbd、rgw、cephfs中其中一项。(默认用户id=admin,如果不需要创建新用户则可跳过此步)如果不输入poolname,默认poolname为 "rbd"确认内核DYNAMIC_DEBUG属性开启。该步骤执行后会输出该用户对应的key。登录client机器。原创 2024-07-19 13:50:53 · 245 阅读 · 0 评论 -
cephfs revoke caps逻辑
即重新执行handle_client_mkdir。client侧经过Client::ms_dispatch2() -> Client::handle_caps() -> Client::handle_cap_grant() -> check_caps() -> send_cap() 发送CEPH_CAP_OP_UPDATE操作(CEPH_MSG_CLIENT_CAPS消息)给server。原创 2024-07-19 13:48:48 · 291 阅读 · 0 评论 -
cephfs client读写流程
fuse_ll_read() -> ll_read() -> Client::_read() -> _read_async() (带缓存) -> ObjectCacher::file_read() -> readx() -> _readx() -> bh_read() -> read_trunc() -> op_submit() -> _op_submit_with_budget() -> _op_submit() -> _send_op() -> send_message()以cephfuse为例。原创 2024-07-19 11:31:46 · 406 阅读 · 0 评论 -
osd挂掉对业务的影响
对于读请求,如果是主osd挂掉了,需要Peering完之后,client收到最新osdmap后重试新的pg主osd读,所以也是约20s。结论:一个osd挂掉,按照默认配置,当时的写请求约卡顿20s;原创 2024-07-19 11:29:48 · 205 阅读 · 0 评论 -
rados localize read
获取自己节点的crush_location,然后在localize read时,拿pg的每个osd和自己的crush_location进行公共祖先最短距离比较。首先,任何节点在启动时会通过main()->global_init()->crush_location.init_on_startup()根据crushmap进行距离打分。根据crushmap进行距离打分。原创 2024-07-19 11:27:39 · 159 阅读 · 0 评论 -
cephrgw lifecycle理解
看代码是WriteOP)3,cls_rgw_lc_get_entry 获取entry,因为entry的状态是processing。3,cls_rgw_lc_get_entry 获取entry,成功,但是为empty。2,cls_rgw_lc_get_head 获取对象的head,成功。2,cls_rgw_lc_get_head 获取对象的head,成功。2,cls_rgw_lc_get_head 获取对象的head,成功。3,cls_rgw_lc_get_entry 获取entry,成功。原创 2024-07-19 11:23:57 · 423 阅读 · 0 评论 -
cephrgw元数据和数据布局
提示:每个rados object有如下几个组成部分,分别是omap(omapheader、omapkey、omapval)、xattr、data,相关的CLI command。如storage_class、mtime、size、etag、content_type、存放的pool。part、stripe(每个part最大15MB,每个stripe最大4MB,stripe是基本单元)[4MB, 15MB]的对象,有head、tail radosobject。bucket中对象的布局信息。原创 2024-07-19 11:16:08 · 505 阅读 · 0 评论 -
juicefs IO流程源码解读
【代码】juicefs IO流程源码解读。原创 2023-04-11 13:34:56 · 533 阅读 · 0 评论 -
cephrgw lifecycle源码解读
LCOpRule: LCWorker逐个处理每个bucket的lifecycle,并执行bucket_lc_process,每个bucket的lifecycle rule,根据不同的前缀,分为若干个LCOpRule,每个匹配的object和对应的LCOpRule将会进入enqueue到对应workpool,workpool中的WorkQ的entry入口将会处理该object和对应LCOpRule,每个LCOpRule对应多个LCOpAction(有Transition,有Expire)原创 2024-04-17 21:46:39 · 232 阅读 · 0 评论 -
ceph osd慢请求排查
可以发现整个请求的耗时主要在header_read event,该耗时显示header_read到all_read期间耗时18.1s,可以分析得出osd在从messenger中读取(0-4M)的数据花了18s,该请求是从10.124.107.8于12:03:35的cephfs client发出,发往osd的,进一步可以去看看src dst在这个时间点的网络链路、CPU情况。原创 2024-04-02 19:32:40 · 483 阅读 · 1 评论 -
ceph ec 一致性原理
简单说来,使用了pglog来实现分片间的一致性,不仅记录了redo信息,而且记录了undo,当primary osd向所有secondary发送写请求时,各个分片写入pglog,并在pginfo中更新自己的last_update(pglog和pginfo以及数据、元数据一起作为一个transaction queue到objectstore),当primary osd收到全部ack后,标记刚才写入的pglog不可回滚(undo信息可以删除,释放空间)更新自身pginfo的last_complete。原创 2024-05-31 22:16:19 · 196 阅读 · 0 评论 -
ubuntu ceph部署
参考文档:http://docs.ceph.org.cn/start/原创 2024-07-05 16:34:22 · 651 阅读 · 0 评论 -
cephfs fuse预读机制
ceph-fuse->ceph ceph-fuse会检测是否是顺序读,根据顺序程度动态调整预读大小128K - 16M之间(client_readahead_min=131072 client_readahead_max_periods=4),实际情况(按照4k顺序读一个大文件)我们抓取到,33%没有预读,23%预读了128K,21%预读了384K,8%预读了1M,剩下的预读范围在[128K, 16M]之间。原创 2024-07-11 15:36:18 · 206 阅读 · 0 评论 -
指定版本ceph-common安装
如,安装15.2.13的ceph-common。原创 2024-07-05 17:21:54 · 455 阅读 · 0 评论