杭州手机网站建设公司 网络服务,网站建设开发详细步骤流程图,百度seoo优化软件,网站建设的功能都需要有哪些方面刘亮奇 架构师技术联盟 2021-04-12 07:50
摘自#xff1a; https://mp.weixin.qq.com/s/o9HH-8TF0DbMqHrvsFh1NA 随着 IOT、大数据、移动互联等应用的暴涨#xff0c;产生的数据也越来越多#xff0c;整个存储市场总量也逐年增长#xff0c;预计到 2021 年分布式存储会占到…刘亮奇 架构师技术联盟 2021-04-12 07:50
摘自 https://mp.weixin.qq.com/s/o9HH-8TF0DbMqHrvsFh1NA 随着 IOT、大数据、移动互联等应用的暴涨产生的数据也越来越多整个存储市场总量也逐年增长预计到 2021 年分布式存储会占到整个存储市场的 50%到 2027 年分布式存储会占到整个市场的 70%。Ceph 则是典型的分布式存储软件的代表。 杉岩数据作为一家软件定义存储商软件的发展与硬件的结合密必不可分与华为共建 ARM 生态是杉岩发展的关键着力点。目前杉岩数据的对象存储 MOS 和块存储 USP 已完成在鲲鹏平台的适配工作且可进行商用。 以下是杉岩数据云存储高级研发工程师刘亮奇在华为开发者大会中关于 Ceph 开发和应用方面的经验分享。 1、Ceph 是什么 在用户层面Ceph 对外提供的三个服务 1、Block storage 即RDB 块存储接口如同一个没有格式化的 U 盘在第一次接入个人 PC 时windows 操作系统会弹出一个格式化的请求界面供用户选择参数如比较重要的文件系统选项有 NTFS、exFAT 等文件系统以供选择格式化完成后的 U 盘才能进行创建目录、拷贝文件等操作形象一点的概括整个块设备可以看成一栋大楼的框架在进入大楼工作生活前需要对这栋大楼进行装修即格式化。而大楼不可能只有一个人所以需要物业进行管理物业可以比作一个文件系统。 2、Object storage 即RADOS GW 对象存储对象存储在大家的生活中也是接触较多的例如我们平常使用的云盘或者我们使用的智能手机都有云备份功能都是基于对象存储的一种业务表现。所以对象存储是为了解决信息化时代海量不规则文件的存储问题。就如世界上没有两片相同的叶子每个人都会产生不同的信息如何解决这些独一无二数据的存储对象存储就是提供了一种解决方法。 3、Flie system 文件系统把 Ceph 提供文件系统服务类比成购买个人电脑的过程DIY 用户可能会买各种硬件、零件组装起来装上操作系统之后才能使用而电脑商家还会提供一个已经预装好 windows 系统的整机供用户选择用户购买之后接通电源开机后可直接使用。Ceph 提供的文件系统服务也就类似于这样的一个整机用户只需将对应的目录挂载到本地即可进行工作。 RGW对象存储接口使用这个接口服务需要配合一些客户端软件当然了,手机上的云备份功能是因为手机操作系统已经内置了 APP 进行支撑所以不需要再额外安装软件。 RBD块存储接口如果使用的是 Linux 系统可以使用内核模块 krbd 直接在本地直接生成一个块设备供用户使用。针对 Windows 系统则可以通过 iSCSI 协议虚拟一块硬盘来供用户使用。 RADOS再往下是整个 Ceph 集群的统一抽象层 RADOS即抽象的对象存储集群。它是上面的所有接口数据经过处理后都会以对象的形式保存在集群当中。同时 RADOS 还确保这些接口数据在整个集群中的一致性而 LIBRADOS主要是访问 RADOS 层的接口库。 接下来是 Ceph 集群中一些比较重要的组件如 mgrmirror 等这些组分布在集群中的各个服务器上未在上图中体现。下面简略说明各个组件的职能 MON即 monitor可以认为是集群的大脑负责集群状态的维护和元数据的管理。 MDS元数据服务它是为 Ceph FS 接口服务提供文件层次结构检索和元数据管理的如果不需要 Ceph FS 服务可以选择不部署该组件。 OSD对象存储设备这是整个集群中用户数据主要承载的终端设备用户所有的数据读写请求基本上最终由 OSD 来负责执行。所以 OSD 的性能决定了整个上层业务的表现。OSD 一般会绑定一个较大的存储空间例如一块硬盘或一个硬盘分区而 OSD 管理存储空间的本地存储接口主要有 File Store 和 Blue Store。当然 File Store 还需要借助本地文件系统比如 XFS来管理存储空间。而 Blue Store 则可以直接接管裸设备这样就可以减少它的 IO 路径以提高性能。 总体来看Ceph 是一个统一的分布式存储系统。它的设计目标是较好的性能可靠性和可扩展性。这是因为从 Ceph 的架构来看没有专门的缓存层所以在性能表现并不是很理想。社区也针对这个问题一直在推动分级缓存(tier)功能但这个功能还没有达到可生产的阶段;所以目前比较通用的做法就是在操作系统层面来缓存 Ceph 数据如内核的通用块层使用 dm-cache、bcache、enhanceIO 等开源软件在操作系统层面将数据缓存在一个较高速的设备(如 SSD)以此提高 Ceph 的性能。
2、Ceph 现有架构与业务存在哪些问题 1、Ceph 数据与内核缓存的割裂问题。以 BlueStore 为例它将 OSD 的元数据保存在 RockDB 中RockDB 又是运行在一个简化的文件系统(Blue FS)之上的此时可以认为 Blue FS 的 IO 就是 OSD 的元数据但对于内核缓存来说它是无法感知 OSD 下发的数据是有元数据和业务数据之分的。 2、内核缓存无法区分 OSD 业务的热点数据和冷数据比如用户配置比较典型的三副本存储策略此时只有主副本数据才会为客户端提供读写服务而从副本则直接不用缓存即可但是内核层缓存是没法区分这种差异的。如果使用的是 DM Cache还会在内存中分配一个空间来缓存部分数据这无还疑会浪费内存资源。 总体来说内核缓存存在浪费 Cache 空间还有 Cache 命中率不高频繁刷新缓存导致缓存设备寿命缩短等缺陷。 3、有何解决方案 在 BlueStore 下发 IO 的地方增加一个适配层用来标记下发 IO 的类型在内核缓存入口处增加一个适配层用来捕捉 OSD 的 IO 类型最后在内核缓存处理时根据 IO 类型进行不同的写回、淘汰策略。 例如将三副本中的两个从副本用 NOCACHE 标签经过适配层随 IO 请求一起带到内核缓存里去这样内核缓存就可以不缓存直接写后备盘。同时可以将 Blue FS 的 IO 标记成元数据类型让其在内核缓存更长时间的驻留。或根据用户业务需求将用户有比较重要的且读写频繁的数据标为高等级其他不重要的数据标成中或低等级然后在内核缓存针对高等级数据采用和元数据一样的处理策略这样就可以根据用户需求来执行不同的淘汰和回写策略。 BlueStore 使用的是 Libaio API 接口来下发 IO 请求此时需要一个 IOCB 结构体作为下发请求的 IO 参数可以通过 io_prep_pwrite 函数生成 iocb 结构体之后把 io flag 设置到 IOCB 的 Flag 结构体当中作为 io_submit 的参数一起提交至内核层内核在 VFS 层时捕捉到 Direct io 时将 flag 转换到通用块设备层的 BIO 结构体里面比如 BIO 的 bi_rw 结构体里面此时位于通用块层的内核缓存即可捕捉到上层业务标签。内核缓存可根据不同的标签执行不同的回写、分配策略比如让元数据更久的驻留在缓存当中或者让高等级的用户数据和元数据执行相同的缓存策略。 4、Ceph 在 ARM 架构上面临的问题与挑战 华为鲲鹏处理器与 Intel Xeon 主要存在如下六个方面的差异 1、ARM 的跨片访问主要反映在内存方面数据是估测值非实测数据不做测评。ARM 相对 X86 来说不占优势所以后面的优化手段中有规避跨片 numa 的操作。 2、矢量运算这方面未获取到鲲鹏的具体参数以 ARM 的 A76 作为参考从目前来看 ARM 也是不占优势的。 3、物理核数ARM 先天就有物理核数上面的优势。 4、协处理器即加速器在加速器方面鲲鹏 920 有 EC/RSA/zlib 等外围协处理器相对通用的 X86 6148 来说是较为丰富这是鲲鹏 920 的优势。 5、内存操作ARM 采用的是 load-store 的微架构简单地理解为ARM 在内存到内存之间的拷贝是需要 CPU 参与的X86 则可以直接做到不用 CPU 参与内存到内存间的拷贝。这是 ARM 微架构决定的。 6、功耗比单论总体的功耗不太准确毕竟功耗还跟启用的物理核数有关系。当然先进的工艺在可以降低功耗。如果论单个物理核的功耗比ARM 确实相对 X86 是有优势的。 5、基于鲲鹏平台的 Ceph 调优 针对鲲鹏平台的 Ceph目前有以下几种主流的优化方案
1、针对跨片 NUMA 操作场景限定进程运行在片内 NUMA 针对跨片 NUMA 操作场景采用将进程限定在片内 NUMA 上面以 Ceph 为例Ceph M 及以后的版本提供一个 OSD_numa_node 参数该参数可以限定整个 OSD 进程所运行的 numa。如果使用的是其他版本的 ceph可以借助 numactl 和 taskset 这两个工具来实现限定进程运行在指定 numa 的功能。 numactl 需要在进程启动时进行设置主要的参数有绑分配内存 NUMA(–membind)、绑进程运行的 NUMA–cpunodebind以及更细的绑进程运行的物理核(–physcpubind)。Taskset 较为灵活可以在进程运行时进行设置。限定了 NUMA 之前对应的硬件都尽量分配在片内的总线下面比如网卡、内存、SSD 等都尽量分配在对应片内总线下面以避免跨片访问。 2、矢量运算短板借助协处理器补齐 矢量运算方面可以借助鲲鹏 920 的平台的加速器华为有提供一些基础设施的接口文档可以根据这些文档进行相应的适配比如这里的纠删码运算(EC)华为提供的接口文档有详细的设置和参数配置需要在代码层面上进行适配此时需要投入工作量进行稳定性方面的测试。 3、增加进/线程数以及内存操作 利用鲲鹏在物理核上的优势可以增加相应处理业务的进程或线程针对业务繁忙的线程可以把线程拆分成两个分配到不同物理核上去。 内存操作方面除了减少内存操作华为还针对 ARM 微架构出了一个补丁该补丁主要优化了内存方面的接口可以去华为的基础设施网站上下载 patch 来提升性能。此外还有其他优化手段 绑定网卡/SSD 中断必须先把 irqbalace 服务关闭否则 irqbalace 服务会将绑定给重新均衡掉。 cgroup 隔离业务针对对繁忙的线程或者进程来说是比较有效的主要是基于 CPU cache 考虑如果 CPU 被切换到不相关的进程和线程的时候会导致 CPU cache 刷新致使命中率下降CPU cache 预读也会浪费内存带宽。同时进程 CPU 一旦被切出就会导致整个流水线被清空/排空的此时并发的指令数也会减少所以对性能还是有影响的。主要还是在业务比较繁忙的时候对性能的改善比较大。 第三方库主要是优化内存的分配和回收效率有 Tcmalloc 和 jemalloc 可选可以去 Tcmalloc 和 jemalloc 的网站去下载相关文件进行阅读。 接下来为大家介绍三种 Ceph 性能观测工具如下图所示 Ceph 的 OSD perf/perf daemon这是 Ceph 自带的工具其中 OSD perf 主要记录 IO 读写的时延可以初步判断到底的瓶颈是否在我们的硬盘上面如果是可以采取相应的优化手段。 perf daemon 主要是记录整个 IO 请求在 Ceph 内部的一些状态的处理流程这些处理流程耗时多少都会通过这个命令导出可以进行初步的诊断。 操作系统——Perf 工具比较常用的 perf top显现当前整个系统的运行情况如上图的右上脚OSD 进程显然是耗费了大量的 CPU可以进行层级下剥查找到热点函数位置再针对性地去优化热点函数。而 perf stat 主要是采集进程在一段时间内的总体的情况。还可以使用 perf record记录数据后续可以结合 FlamGraph 生成一个火焰图这种火焰图相对来说比较直观。主要关注一些平头的函数调用图因为这里耗费的 cpu 时间比重比较大是优化的目标。 Systemtap主要在 Redhat 系统用得比较多。通过采集内核函数、系统调用、用户函数的运行信息、函数出入口数据等根据这些采集的数据进行函数级别的分析。如基于 openresty-systemtap-toolkit 工具进行二次开发。通过工具就可以去分析整个系统或者是程序在哪里有瓶颈点然后再针对瓶颈点进行性能优化。 6、优化后的 Ceph 存储系统性能如何 兼容性方面从开始到结束整个过程没有遇到比较大的阻塞点依赖库和部分技术问题在华为的基础设施网站上能够找到解决方法将 Ceph 移植到鲲鹏平台上的整个流程较为顺利。 优化的性能基于现有服务器配置进行的优化前后对比这里的测试并未鲲鹏 CPU 的极限主要的瓶颈点是在硬盘上。主要是展示经过上面介绍的优化方法、手段进行优化后的成果。如表所示可以看到优化后的性能是有改善的。 低功耗主要体现在 ARM 的单物理核的功耗确实比 X86 要低的所以在后期运营成本上具备优势。 下面介绍一下我们的块存储产品运行在鲲鹏平台上的状况主界面显示的是整个块存储产品集群的状态节点信息部分上面部署了 monitor 和 OSD 等组件这里的服务器信息可以看出是华为的 TaiShan 服务器TaiShan 200型号 2280的服务器使用的就鲲鹏 920 的处理器。 其他管理功能例如卷管理Linux 系统可以通过内核的 krbd 模块实现本地挂载也可以走 iSCSI 协议挂载到 windows 系统上供用户使用图。当了还有其他的功能这就不展开了。 6、未来的展望和计划 首先是基于 TaiShan 服务器的一个长远计划例如发布一个基于全闪存场景的产品这种场景下所有的硬盘性能都比较高而传统以太网网络将是一个瓶颈现在 TaiShan 服务器刚好支持 RDMA 功能为全闪存场景的部署铺平了道路无需额外适配、调优网络端口了。 seastar 对于 ARM 架构来说多核竞争中跨片访问时性能处于劣势此时采用无共享编程的 seastar 框架有利于规避 ARM 跨片访问的劣势seastar 架构的改造社区也在积极投入我们也会持续跟进。 最后是安全存储产品对数据加解密和解压缩的处理较为重要而鲲鹏外围加速器 zlib/rsa/md5/sm3 能够提供高效的数据安全处理流程。 关于强耦合的内核缓存改造后是否需要重新编译操作系统不需要在 VFS 层时是通过 kernel hacking 的方式处理 I/O 的不需要改动内核原有的逻辑只需将修改后的 KO 加载到操作系统就可以处理我们定制的 IO 了。 为什么不考虑将缓存做到 blue Store 里面Blue Store 在社区当时设计的目标是面向未来全闪存场景的是没有考虑过混合场景的而且混合场景只是一个过渡阶段并不长远所以社区在设计时就没有考虑过加缓存如果将缓存做到 Blue Store 的话是与社区设计理念相悖同时导致整个 Blue Store 处理异常复杂无论是以后跟进社区还是向社区推送改动都比较麻烦。
