「PPP」- 报文交换
链路建立流程
建立 PPP 链路，需要进行三个阶段的协商： 1）链路协商：通过LCP报文进行链路参数协商，建立链路层连接； 2）认证协商（可选）：通过链路建立阶段协商的认证方式进行链路认证； 3）网络协商 ：通过 NCP 协商，来选择和配置一个网络层协议，并进行网络层参数协商；
链路接口状态机
PPP协商由链路两端的接口完成。接口的状态表示了协议的协商阶段；
第一步、链路协商过程（LCP）
LCP 协商由不同的 LCP 报文交互完成，相互协商： 1）协商由任意一方发送 Configure-Request 报文发起； 2）如果对端接收此报文且参数匹配，则通过回复 Configure-Ack 响应协商成功；
参数匹配，协商成功
Magic Number：用于防环；
Configure-Request 需要相互发送。
参数相异，重新协商
在LCP报文交互中出现LCP参数不匹配时，接收方回复 Configure-NAK 响应告知对端修改参数然后重新协商；
参数未知，重新协商
在LCP报文交互中出现LCP参数不识别时，接收方回复 Configure-Reject 响应告知对端删除不识别的参数，然后重新协商；
第二步、认证协商过程（Auth）
链路协商成功后，进行认证协商（此过程可选）。认证协商有两种模式：PAP；CHAP；
PAP，Password Authentication Protocol
PAP 认证双方有两次握手。协商报文以明文的形式在链路上传输；
Auehenticate-Request，Authenticate-ACK（Authenticate-NAK）
CHAP，Challenge Handshake Authentication Protocol
CHAP认证双方有三次握手。协商报文被 HASH 后再在链路上传输；
第三步、网络协商过程（Network）
PPP认证协商后，双方进入NCP协商阶段，协商在数据链路上所传输的数据包的格式与类型；
以常见的 IPCP 协议为例，它分为： 1）静态地址协商。需要事先手动在链路两端配置IP地址，协商过程只是通知对方； 2）动态地址协商；
静态网络地址协商
动态网络地址协商
动态地址协商支持 PPP 链路一端为对端配置地址，即：某端未配置地址，另端已配置地址，此时零端负责分配地址；[……]
「Huawei VRP」- 配置 PPP 协议
配置命令（Huawei）
链路配置
// 配置接口封装PPP协议
// 在接口视图下，将接口封装协议改为 ppp，华为串行接口默认封装协议为ppp。
[Huawei-Serial0/0/0] link-protocol ppp
// 配置协商超时时间间隔
// 在PPP LCP协商过程中，本端设备会向对端设备发送LCP协商报文，如果在指定协商时间间隔内没有收到对端的应答报文，则重新发送。
[Huawei-Serial0/0/0] ppp timer negotiate seconds
认证配置
PAP 认证配置命令
// 远程：配置验证方以PAP方式认证对端
// 首先需要通过AAA将被验证方的用户名和密码加入本地用户列表，然后选择认证模式。
[Huawei-aaa] local-user user-name password { cipher | irreversible-cipher } password
[Huawei-aaa] local-user user-name service-type ppp
[Huawei-Serial0/0/0] ppp authentication-mode pap
// 本地：配置被验证方以PAP方式被对端认证
// 配置本地被对端以PAP方式验证时，本地发送PAP用户名和口令。
[Huawei-Serial0/0/0] ppp pap local-user user-name password { cipher | simple } password
CHAP 认证配置命令
// 远程：配置验证方以CHAP方式认证对端
[Huawei-aaa] local-user user-name password { cipher | irreversible-cipher } password
[Huawei-aaa] local-user user-name service-type ppp
[Huawei-Serial0/0/0] ppp authentication-mode chap
// 本地：配置被验证方以CHAP方式被对端认证
// 配置本地用户名，配置本地被对端以CHAP方式验证时的口令。
[Huawei-Serial0/0/0] ppp chap user user-name
[Huawei-Serial0/0/0] ppp chap password { cipher | simple } password
实验：PPP, PAP
远端配置： 1）接口链路类型： 2）创建用户，指定服务类型： 3）接口认证类型：
本端配置： 1）接口链路类型： 2）接口认证：ppp pap …[……]
「PPP」- Point-to-Point Protocol
问题描述
PPP，Point-to-Point Protocol，点对点协议。
而 ppp (Paul’s PPP Package)，实现 PPP 协议。
解决方案
安装服务
可以去官网下载ppp。官网中也有ppp的Git仓库的地址。最开始我下载了ppp-2.4.7.tar.gz，但是编译中有错误，虽然通过了，但是有错误，与我的内核版本头文件有关。然后我又重新从Git仓库中检出master分支重新编译，这时候不再有编译错误。
内核要支持PPP驱动 -> Device Drivers
-> Network device support
阅读README及README.linux进行安装 如果是Linux下编译，先阅读源码目录下的README和README.linux，里面有详细的指引。
相关文件
.
├── include
│ └── pppd # 相关的头文件
├── lib
│ └── pppd # 相关的.SO文件
└── sbin
├── chat
├── pppd
├── pppdump
├── pppoe-discovery
└── pppstats
参考文献
Homepage Wikipedia / PPP[……]
「SSH」- 概念、术语
协议结构
在SSH 协议框架中，最主要的部分是三个协议： 1）传输层协议：提供 版本协商、加密算法协商、密钥交换、服务端认证、信息完整性支持； 2）用户认证协议：为服务器提供客户端的身份鉴别； 3）连接协议：将加密的信息隧道复用为多个逻辑通道，提供给高层的应用协议（STelnet、SFTP）使用；各种高层应用协议可以相对地独立于SSH基本体系之外，并依靠这个基本框架，通过连接协议使用SSH的安全机制。
SSH 传输层协议
SSH 传输层协议，是个安全传输协议。SSH 传输层通常建立在TCP/IP连接上，但也可以在任何其他可靠的数据流上建立。 SSH 传输层协议协商所有的密钥交换算法、公钥算法、对称加密算法、消息认证算法等。
算法类别 | 算法功能 | 算法名称 1）密钥交换算法 | 用于产生会话密钥 | diffie-hellman-group14-sha1, diffie-hellman-group1-sha1… 2）公钥算法 | 用于进行数字签名和用户认证 | ssh-rsa,ssh-dss … 3）对称加密算法 | 用于会话的加密 | aes128-ctr,3des-cbc … 4）消息认证算法 | 用于数据完整性认证 | hmac-sha1,hmac-md5 …
完美前向保密
完美前向保密（Perfect Forward Secrecy，PFS），是安全通讯协议中的一种属性，PFS由Christoph G. Günther在1990年提出，其最初用于定义会话密钥交换协议的一种安全性，指的是用来产生会话密钥的长期密钥（long-term key，通常为私钥或者相关认证材料）的泄露，不会导致过去的会话密钥（session key）泄漏。前向保密能够保护历史通讯和会话不受密码或密钥在未来暴露的威胁，即使攻击者进行主动干预也是如此。
SSH传输层协议采用的Diffie-Hellman密钥交换算法可以提供完美的前向保密性（PFS）。
更多参考 RFC4251 9.3.7 Forward Secrecy 小节，https://www.ietf.org/rfc/rfc4251.txt
SSH 用户认证协议
SSH用户认证协议为服务器提供客户端的用户鉴别。它运行在传输层协议上。
SSH用户认证协议提供两种认证方法： 1）口令认证：客户端通过用户名和密码登录到服务器，完成用户认证。 2）公钥认证：服务器通过公钥解密客户端的数字签名，完成用户认证。
公钥是用来解密信息的，确保让别人知道这条信息是真的，是有自己本人发布的，是完整正确的。接收者由此可知这条信息确实来自于拥有私钥的某人，这被称作数字签名，公钥的形式就是数字证书。
当此协议启动时，它从SSH传输层协议接收会话ID[……]
「SSH」- 原理简述
在整个通讯过程中，为实现 SSH 的安全连接，Client 与 Sever 要经历如下五个阶段： 1）版本协商阶段：目前 SSH 包括 SSH1 和 SSH2 两个版本，双方通过版本协商确定使用的版本； 2）算法协商阶段：SSH 支持多种加密算法，双方根据本端和对端支持的算法，协商出最终使用的加密算法； 3）密钥交换阶段：通过密钥交换算法生成会话密钥，此后双方的会话均通过会话密钥加密； 4）用户认证阶段：SSH Client 向 Server 发起认证请求， Server 对 Client 进行认证； 5）会话交互阶段：当认证通过后，Server 和 Client 进行信息的交互；
版本协商阶段
客户端和服务器交互 SSH 版本协商报文，确定 V1 或 V2 版本
1）服务端打开端口 22，等待客户连接。客户端向服务端发起 TCP 连接，双方完成握手并建立连接。 3）客户端向服务端发送第一个报文，包括版本标志字符串，格式为 “协议版本号 次协议版本号 软件版本号”。 4）服务端收到报文后，解析协议版本号：如果客户端的协议版本号比自己的低，且服务端能支持客户端的低版本，就使用客户端的协议号，否则使用自己的协议版本号。
算法协商阶段
客户端和服务器交互自己支持的算法列表，该列表包括四种算法的具体算法名称。
算法协商过程为： 1）从客户端发来的算法列表取出第一个算法，服务器在自身的算法列表中查找，若匹配上相同的算法，则协商成功，继续协商下一种算法；否则继续从客户端的该种算法列表中取出下一个算法，在服务器端的算法列表中匹配，直到匹配成功。
密钥交换阶段
根据密钥交换算法，双方动态地产生会话密钥用于后续会话加密。会话密钥无法被第三者截获，安全可靠。
客户端和服务器首先约定两个公开的质数p和g。 客户端和服务器各自随机产生一个数Xc，Xs，作为自己的私钥。 各自计算出自己的公钥Yc，Ys。 交换公钥Yc，Ys。 根据公私钥计算出加密用的会话密钥。
具体的密钥交换算法为DH算法，DH算法基于数学的离散对数（不再详述）。在密钥交换过程中私钥Xc，Xs始终是保密不传播的，且由于离散对数计算的困难性，其他用户即使获取 p、g、Yc、Ys 也无法推断出私钥 Xc、Xs，从而保证了会话密钥的安全性。
注意，该阶段产生的公私钥仅用于产生会话密钥，与后续用户认证无关。密钥交换阶段完成后，后续所有报文交互均为会话密钥加密过的报文。
用户认证阶段
用户认证阶段有口令认证和公钥认证两种方式。
口令认证
客户端发送携带用户名和口令的认证请求，服务器与本地用户数据进行匹配认证。[……]
「NETWORKING」- 软件实现网络（搭建，软路由，路由器，软件）
问题描述
无意间在油管上看见 Openwrt/LEDE 搭建路由的方法（一个 U 盘优盘就翻墙免费拥有 VPN 翻墙路由器的两种方法 Openwrt/LEDE 软路由 U 盘优盘的制作 ButterflyVPN 评测）。我们有心搭建，可惜无用（没有需求），所有也没有搭建，但依旧记录下这就事情。如果日后真的有必要，我们将会按照视频中的方法搭建自己的“高级路由器”；
# 02/06/2022 数月前，我们开始探索软路由相关的应用技术，目的是为我们的 边缘数据中心（Edge DC） 提供网关设备；
# 03/29/2023 针对该部分笔记，其内容逐渐倾向于记录我们构建家庭网络的过程；
解决方案
我们需要准备如下物件： 1）设备：旧电脑，工控机； 2）存储：（可选）优盘； 3）固件：选择路由系统固件，比如 LEDE、OpenWrt 等等；[……]
「CEPH」- RBD 镜像
解决方案
配置RBD映像可以在不同的Ceph集群之间实现RBD块设备的异步复制，以实现容灾。
原理简述
RBD Mirror的核心原理是使用日志回放（JournalReplay）功能保证主集群RBD和次集群RBD的数据副本一致。注意，这里的日志并不是Ceph OSD日志。
该机制使用异步操作，在网络上将 Primary RBD Image 复制到目标 Seconadry RBD Image。如果 Primary RBDImage的集群不可用，你可以使用远程集群上的 Secondary RBDImage，然后重新启动该映像的应用程序。从Source RBD Image故障转移到Mirror RBD Image时，必须降级Source RBD Image，同时升级Target RBD Image。Image降级后，将变为锁定且不可用状态；升级后，将进入读写模式，可被使用。RBD映像功能需要rbd-mirror软件包。该软件包需要安装在两个集群的服务器上，并且每个Ceph集群必须至少配置一个MirrorAgent。
数据复制方向
RBD Mirror支持两种复制：单向复制、双向复制。
在单向复制下，主集群的RBD Image读/写可用，而远程Secondary Cluster仅容纳镜像，并不提供对外服务。Mirror agent仅在Secondary Cluster上，Mirror是Secondary Cluster上运行的Mirror Agent远程拉取主集群上的RBD Image。此模式下，你可以配置多个辅Secondary Cluster。图11-3是RBDMirror单向复制的数据流向。
在双向复制下，每个RBD Mirror实例必须能够同时连接到另一个Ceph集群。此外，网络必须在两个数据中心站点之间具有足够的带宽，以处理镜像。图11-4是双向复制模式下的数据流向。这里要强调的是，虽然是双向复制模式，但是并不是业务双活，不能同时在两个集群中对相同的RBD数据进行读写。因为Ceph的RBD Mirror是异步的。双向复制模式要求单向写入，一旦主集群不可写，就可以配置Secondary Cluster作为读写集群，待主集群恢复后，Secondary ClusterRBD映射到主集群。本质上，双向复制和单向复制操作机制一样。
数据复制模式
RBD Mirror 有两种复制模式：
1）Pool 模式下，Mirror Pool中创建的每个RBDImage自动启动Mirror开始同步。在主站点MirrorPool中创建Image后，远程备站点自动创建副本Image。
2）Image 模式下，必须为每个RBD Image分别启动Mirror，并且必须明确指定要在两个集群之间复制的RBD[……]
「CEPH」- CephFS 数据备份
考虑到 CephFS 已经是文件形式的存储，用户的最终使用习惯和操作系统上的一样，所以官方未提供专用于 CephFS 容灾备份的集成方案，建议使用网络备份软件来设置容灾的集成方案。
如果 CephFS 的元数据损坏，Ceph 提供了修复工具 cephfs-journal-tool；[……]
「CEPH」- 对象存储（Object Storage，S3，Swift）
问题描述
S3 兼容接口提供了一套简单的 Web 服务接口，可随时随地通过 HTTP 的方式在网络上的任何位置存储和检索任意数量的数据，是一套非常实用的对象存储服务标准。很多互联网公司的产品，比如图片、视频一类资源的存储与发布等都是借助这套标准服务来实现的，节约了大量的采购、开发和部署运维成本，特别适合一次写入，多用户同时读取的场景；
解决方案
RGW（RADOS Gateway，Ceph 对象存储网关服务），是基于 librados 封装而实现的 FastCGI 服务，对外提供 RESTful 风格的对象存储数据访问和管理接口。它提供与 OpenStack Swift 和 Amazon S3 兼容的接口；
原理简述
RGW，建立在 librados 层之上，提供对象存储接口，为使用标准对象存储 API 的客户端提供访问 Ceph Cluster 的 RESTfulAPI 接口； RGW，使用 librgw（RADOS 网关库）和 librados，允许应用程序与 Ceph 对象存储建立连接； radosgw（核心守护进程）提供以 librados 为基础封装的接口，RGW 通常将自己的 Web 服务器作为前端来处理请求； Client 使用 API 与 RGW 通信，RGW 通过 librados 与 Ceph Cluster 通信；
特性特征
S3 and Swift
RGW 支持两个接口： 1）提供 S3 兼容接口：兼容大部分 Amazon S3 API 标准，详见 S3 接口兼容列表；（Ceph Object Gateway S3 API） 2）提供 Swift 兼容接口：兼容大部分 OpenStack Swift API 接口；（Ceph Object Gateway Swift API/FEATURES SUPPORT）
S3 和 Swift API 共享同个命名空间，所以可以使用其中一个 API 写入数据，使用另一个 API 检索数据；
Admin Ops API
提供 Ceph Admin API 支持：它们用于通过原生 API 调用来管理 Ceph 存储集群；（Admin Operations）
User Managerment
RGW 具有独立的用户管理功能，其拥有自己的用户集，与 Ceph Cluster 用户不同。换句话说，RGW 的客户端通过 Amazon S3 或 OpenStack Swift API 来使用自己的用户集进行身份验证。我们可以使用 radosgw-admin 工具或基于 LDAP 的外部身份验证服务来配置用户；
其他特性
Ceph 还支持多租户对象存储，通过 RESTful API 存取；
Ceph 对象存[……]
「Ceph」- 对象存储：多站点
Zonegroup：由多个 Zone 组成，应该有一个主 Zonegroup 来处理对系统配置的更改；
Zone：由一个或多个 Ceph 对象网关实例组成的逻辑组。Zone 的配置不同于典型的 Ceph 配置，因为并非所有设置最终都存储在 Ceph 配置文件中。Zonegroup 中必须指定一个 Zone 为主 Zone。主 Zone 将处理所有桶和用户请求。从 Zone 可以接收桶和用户请求，但会将它们重定向到主 Zone。如果主 Zone 崩溃，桶和用户请求处理失败。我们可以将从 Zone 升级为主 Zone。但是，升级从 Zone 为主 Zone 是一项复杂的操作，建议仅在主 Zone 长时间崩溃时执行；
Realm：代表由一个或多个 Zonegroup 组成的唯一的全局命名空间。每个 Zonegroup 包含一个或多个 Zone，每个 Zone 包含存储对象数据的桶。Realm 还包含 Period，每个 Period 展示某一时间段内 Zonegroup 和 Zone 配置的状态；
Period：每个 Period 展示唯一的 ID 和 Epoch。每次提交操作都会增加 Period 中的 Epoch。每个 Realm 都有一个关联的当前 Period，其中包含 Zonegroup 和存储策略的当前配置状态。每次更改 Zonegroup 或 Zone 时操作 Period 并提交。每个 Cluster Map 都保留其版本的历史记录。这些版本中的每一个版本都称为一个 Epoch；
参考文献
Multi-Site — Ceph Documentation[……]
「CEPH」- 模块交互过程
模块交互过程
首先通过 Ceph Client 接口将文件、视频、图片等数据写入，并将用户数据分割成对象（对象和定义的存储池关联），将对象放入存储池生成规则集，由 CRUSH 算法计算出 PG，最后将 PG 关联到具体服务器的硬盘，[……]
「CEPH」- RGW 管理维护
[WIP] 当创建用户时，命令挂起
问题描述：当创建用户时，命令挂起，很久才返回，并伴随错误，而继续创建新用户则不会再出现该问题；
root@ceph-node-09:/# radosgw-admin user create –uid=10 –display-name=’AAAAAA’
2022-06-04T15:06:19.301+0000 7f30db75c1c0 1 int RGWSI_Notify::robust_notify(RGWSI_RADOS::Obj&, const RGWCacheNotifyInfo&, optional_yield):394 Notify failed on object us-east-1.rgw.meta:users.uid:10: (110) Connection timed out
2022-06-04T15:06:19.301+0000 7f30db75c1c0 1 int RGWSI_Notify::robust_notify(RGWSI_RADOS::Obj&, const RGWCacheNotifyInfo&, optional_yield):397 Backtrace: : ceph version 15.2.16 (d46a73d6d0a67a79558054a3a5a72cb561724974) octopus (stable)
1: (RGWSI_Notif[……]
「CEPH」- 规划高可用集群
问题描述
投产 Ceph 之前，需要做好充分的集群规划，才能在后续实践中得到满意的集群性能，同时降低运维难度。如果集群规划不当，将可能给集群扩容、升级、维护等带来很多麻烦；
解决方案
Ch.1 需求确认 Ch.2 版本选择 Ch.3 硬件选型 Ch.4 操作系统 Ch.5 服务规划 Ch.6 配置策略
Ch.1 确认场景
根据存储需求和使用场景，来制定 Ceph 的硬件选型需要；
高性能场景（IOPS）
特征：这种配置的类型亮点在于它在低 TCO（ownership 的总消耗）下每秒拥有最高的 IOPS；
实现：典型的做法是使用包含了更快的 SSD 硬盘、PCIe SSD、NVMe 做数据存储的高性能节点；
场景：通常用于块存储；也可以用在高 IOPS 的工作负载上：随着闪存使用的增加，企业越来越多地将 IOPS 密集型工作负载（例如 MySQL、MariaDB 或 PostgreSQL 等等）托管在 Ceph 集群，以便提高私有云存储解决方案性能，并支持结构化数据；
推荐配置：
CPU：假定主频 2GHz，则每个 NVMe SSD 使用 6vCPU，每个非 NVMe SSD 使用 2vCPU； RAM：16GB + OSD * 5GB（16GB 作为基线，每个 OSD 使用 5GB 内存） DISK：NVMe SSD Bluestore WAL/DB：可与 NVMe SSD 同盘； 磁盘控制器：PCIe OSD 进程数：每个 NVMe SSD 分配 OSD * 2 进程； 网络：每 OSD * 2 使用 10GB 网络；
通用场景（Bandwidth）
特征：亮点在于高吞吐量和每吞吐量的低功耗；
实现：通用的做法是拥有一个高带宽、物理隔离的双重网络，使用 SSD 和 PCIe SSD 做 OSD 日志盘；
场景：这种方法常用于块存储，如果你的应用场景需要高性能的对象存储和文件存储，也可以考虑使用；对于存储非结构化数据的用户，制定吞吐量大的方案即可；
Ceph 集群通常可以存储半结构化数据或非结构化数据，一般是顺序读写较大的文件，需要提供很大的带宽。存储服务器上的磁盘可以使用基础 SSD 做日志加速的 HDD 盘；
推荐配置： 1）CPU：假定主频 2GHz，则每个 HDD 使用 2vCPU，通常不需要使用 SSD 存储； 2）RAM：16GB + OSD * 5GB（16GB 作为基线，每个 OSD 使用 5GB 内存） 3）DISK：HDD (7200 RPM SATA/SAS) 4）Bluestore WAL/DB：使用 SAS SSD / NVMe SSD 进行加速； 5）磁盘控制器：HBA（JBOD） 6）OSD 进程：每个 HDD[……]
「CEPH」- 备份，恢复，迁移
数据备份：防止地域集群故障
容灾即灾难恢复、容灾备份或灾备，是数据中心业务连续性和可靠性中非常重要的考量指标。如果在生产系统上线后还没有做好容灾方案，那么一旦数据中心出现区域性故障，轻则业务中断，重则数据丢失。而容灾更多是指 系统在遭受自然灾害、人为操作失误 等情况下对业务数据的恢复能力；
当建设 Ceph Cluster 完毕后，单集群模式可以通过副本或者纠删码方式实现数据的高可用性，保证数据盘在部分损坏（可容许损坏数量范围内）的情况下，仍然能够持续提供服务，不会导致数据丢失；
但是，在单集群整体故障的情况下，实现数据可靠就需要提出完整的容灾方案；
解决方案
Ceph 的使用接口主要包括三种：对象存储接口、块存储接口、文件存储接口。除了这三种传统接口外，Ceph 还提供了在这三种接口上封装的其他服务，比如 iSCSI、NFS、Samba 等。对于不同接口保存的数据，我们都需要对其设计相应的容灾方案，保证在数据中心单 Ceph 集群出现故障后，相应存储接口保存的数据在远端容灾集群中有副本。
典型的 Ceph 容灾方案要求有两个 Ceph 集群：一个集群提供业务，另一个集群提供备份；
数据恢复：
为了能够细粒度的进行数据恢复，Ceph 提供 ceph-objectstore-tool 命令，用于低层次 PG 和对象的数据恢复；
使用该命令需要具有一定的知识背景，否则可能会造成数据丢失；
WIP[……]
「Ceph」- 运行观测
该笔记将记录：与 Ceph 有关的监控解决方案，但并不涉及集群的日常管理运维过程中的状态查看；
监控系统方案
GitHub – ceph/calamari，最后一次更新是 Jan 4, 2018（11/22/2022） GitHub – ceph/calamari-clients，已归档； GitHub – ceph/romana，已归档；
常用监控命令
需要查看的对象有：MON OSD MDS PG；RBD RADOSGW GEPHFS Client；
=
Auth
# ceph auth list
CRUSH map
# ceph osd crush dump
# ceph osd crush rule list
# ceph osd crush rule dump <crush_rule_name>
# ceph osd find <Numeric_OSD_ID>
Ceph MDS
# ceph mds stat
# ceph mds dump
# ceph fs ls[……]
「CEPH」- 性能提升
问题描述
在 Ceph 集群建设完毕后，需要对集群的性能进行测试，获取相应的测试指标（以确定集群是否能够满足性能要求），并针对测试指标对 Ceph 集群进行调优（以尽量减少软件层面带来的性能损耗，尽可能大地发挥硬件的性能优势，达到预期的性能要求）。
虽然，经过多年的研究，在 Linux 操作系统和 Ceph 自身性能上进行了优化。但是，每套 Ceph 集群的规模及场景都有差别，很难给出万能的参数让性能达到预期。要综合考虑各方面因素进行调优，避免参数之间相互影响，而无法获得良好的整体性能。
该笔记将记录：概述 Ceph Cluster 进行基准测试的方法；概述性能调优的方法；针对特定性能场景的解决办法；
解决方案
需要关注的对象
性能调优是为 Ceph 集群定制一个或多个系统的过程，以便使 Ceph 具有最佳的响应时间或吞吐量。
衡量 Ceph 集群的性能有 3 个指标： 1）延迟（Latency）： 2）每秒读写次数（IOPS）： 3）吞吐量（Latency）：我们还可以测量从客户端到服务器网络甚至整个系统的吞吐量；
需要得到的结果
降低 Latency；提高 IOPS；提高 Bandwidth；
提升性能的方法
性能提升需要从两方面入手： 1）性能测试：针对硬件及当前系统进行测试，以了解最大性能； 2）性能调优：根据硬件负载模型、性能表现，来调整参数；[……]
「Ceph」- 性能测试，块存储性能
问题描述
在 Ceph 上线前，需要进行性能测试，以确定 Ceph 是否能够满足自己的场景需求。我们的目的是清楚掌握当前 Ceph Cluster 性能，所以要针对 Ceph Cluster 进行性能测试。
解决方案
在进行测试时，我们要清楚以下几点：
测试对象
Hardware：Network；Raw Block Device； Ceph Cluster：RDB；CephFS；RGW；
测试指标
IOPS、MBPS、Latency；
测试方法
在宣布测试结果时，需要说明该测试的工具、参数、方法，以便于比较。
测试工具：
1）Fio：灵活的I/O测试工具，通过其广泛的配置选项，测试各种复杂的I/O性能。它拥有适用于本地块设备和RBD的插件，这意味着可以直接从Ceph集群测试RBD，也可以通过Linux内核驱动程序将RBD映射到客户端，然后使用Fio对通过客户端映射的块设备进行I/O性能测试。
2）S3bench：提供了针对兼容S3接口的基本吞吐量测试功能。它执行一系列put操作，然后执行一系列get操作，并显示相应的统计信息。该工具使用AWS GoSDK。
3）Ping：除了能够诊断许多网络问题外，Ping对网络连接的延迟测试也非常有用。
4）iPerf：其允许进行一系列网络测试，以确定两台服务器之间的带宽。该工具是最常用的网络性能测试工具。
5）RADOS：Ceph自带的性能测试工具，包括对带宽等指标的全面测试。
测试参数：
在测试过程中，我们将调整 IO Size、寻址空间、队列深度、读写模式、随机/顺序模式 等等参数；
测试方法：
测试是为了对比，所以需要定性和定量。基准测试，实际上是一种比较。基准测试（benchmarking）是一种测量和评估软件性能指标的活动。你可以在某个时候通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化后，再进行一次基准测试以确定那些变化对性能的影响。这是基准测试最常见的用途。
基准测试可以在不同层级执行：
第一步、获取硬件基准性能（针对存储集群底层硬件的基准测试）
如果想要知道 Ceph Cluster 性能，那首先要知道可能的集群最大性能。而最大性能不可能超过基础设施的性能，所以我们首先将针对硬件进行独立测试，以获取特定硬件的最大性能；
我们需要获取两个基础设施的指标：
1）[……]
「CEPH」- 性能测试：RADOS 性能测试
rados bench
命令行参数：
bench <seconds> write|seq|rand [-t concurrent_operations] [–no-cleanup] [–run-name run_name] [–no-hints] [–reuse-bench]
default is 16 concurrent IOs and 4 MB ops
default is to clean up after write benchmark
default run-name is ‘benchmark_last_metadata’
// 需要先运行 write 测试，以写入数据，用于后面的读取测试；
// seq and rand are read benchmarks, either sequential or random.
// 但是，我们没有找到该 write 属于 rand 还是 seq 模式；
通过 rados bench 命令：
# rados bench 60 write -p benchmark-rados-bench –no-cleanup -t 32 -block_size 4K
hints = 1
Maintaining 32 concurrent writes of 1048576 bytes to objects of size 1048576 for up to 60 seconds or 0 objects
Object prefix: benchmark_data_laptop-asus-k53sd_4090139
sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s)
…
48 32 1581 1549 32.2665 42 0.851067 0.979014
49 32 1608 1576 32.1589 27 0.863697 0.980051
50 32 1652 1620 32.3956 44 0.556496 0.983059
51 32 1686 1654 32.427 34 0.4329[……]
「CEPH」- 性能测试：RBD 性能测试
测试用例
针对 RBD 设备的性能测试，可以设置具体的性能指标。通过这些指标可以综合衡量 Ceph 集群中 RBD 的极限性能；
rbd bench-write
# rbd bench-write
rbd: bench-write is deprecated, use rbd bench –io-type write …
rbd: image name was not specified
rbd bench-write，该命令已废弃，建议使用 rbd bench 命令；
rbd bench
Ceph Documentation/rbd/bench
# rbd help bench
usage: rbd bench [–pool <pool>] [–namespace <namespace>] [–image <image>]
[–io-size <io-size>] [–io-threads <io-threads>]
[–io-total <io-total>] [–io-pattern <io-pattern>]
[–rw-mix-read <rw-mix-read>] –io-type <io-type>
<image-spec>
创建用于性能测试的磁盘：
rbd -p benchmark-rados-bench create benchmark-rbd-bench –size 20G
rbd -p benchmark-rados-bench info –image benchmark-rbd-bench
rbd -p benchmark-rados-bench map benchmark-rbd-bench
rbd showmapped
Bandwidth
Write
rbd bench –pool benchmark-rados-bench –image benchmark-rbd-bench \
–io-size 4M –io-threads 32 –io-total 10G –io-pattern seq –io-type write
…
308 2496 6.16315 25 MiB/s
312 2528 6.18411 25 MiB/s
elapsed: 316[……]
「CEPH」- 测试 S3 性能
# ./s3bench –accessKey=xxx –accessSecret=xxx \
–bucket=tb1 –endpoint=http://mon1.ceph1.example.com:8080,http://mon2.ceph1.example.com:8080,http://mon3.ceph1.example.com:8080 \
–numClients=3 –numSamples=10 –objectSize=838860800[……]
「CEPH」- 性能调优
问题描述
该笔记将记录：与 Ceph Cluster 相关的性能调优方法，以及相关问题的解决办法；
解决方案
存储系统的优化方法如下： 1）增加并行度； 2）降低服务时间；
硬件环境调优
操作系统调优
服务参数调优
针对参数调优配置，从如下方向入手： 1）服务端参数优化； 2）客户端参数优化；
内存分析
通常用于内存泄漏等等 BUG 排查的场景中；
ceph tell osd.0 heap start_profiler …（经过一段时间运行，或者手动产生一些负载） ceph tell osd.0 heap stats
# 导出文件，并通过google-perftools 查看 ceph tell osd.0 heap dump pprof –text /usr/bin/ceph-osd /var/log/ceph/osd.0.profile.001.heap[……]
「CEPH」- 性能总结
赶不上本地 SSD。本地 SSD（尤其是 NVMe）现在非常快，它们的延迟约为 0.05 毫秒。SDS 很难达到相同的结果，击败它几乎是不可能的。仅网络就吃掉了那些 0.05 毫秒……
在 SATA SSD 的集群中，实现了 0.14 毫秒的延迟（读取和写入），已经很快了；
我们的目标：Ceph 在同一硬件上实现 1 ms 的写入和 0.57ms 的读取。
Vitastor targets SSD and SSD+HDD clusters with at least 10 Gbit/s network, supports TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms with proper hardware which is ~10 times faster than other popular SDS’s like Ceph or internal systems of public clouds.
参考文献
YourcmcWiki/Ceph performance[……]
「Ceph」- 维护管理：CRUSH map
修改 CRUSH Map 内容（改）
Ceph Documentation/CRUSH Maps
直接修改 CRUSH Map 内容
# 导出当前 CRUSH Map 内容（二进制）
ceph osd getcrushmap -o crushmap_compiled_file
# 导出结果转成文本文件
crushtool -d crushmap_compiled_file -o crushmap_decompiled_file
# 修改文件内容
vim crushmap_decompiled_file
# 生成新的 CRUSH Map 文件
crushtool -c crushmap_decompiled_file -o crushmap_compiled_file.new
# 测试文件内容
crushtool –test -i ./crushmap_compiled_file.new –num-rep 3 –rule 1 –show-mappings
# 应用新的 CRUSH Map 文件
ceph osd setcrushmap -i crushmap_compiled_file.new
# 针对 CRUSH Map 的编辑，是立即生效的。等待变更……
ceph status
# 重新查看新的集群映射图
ceph osd tree
通过命令修改 CRUSH Map 信息
命令行无法直接修改 CRUSH Map 的内容，但是部分针对 Ceph Cluster 的操作能够反馈到 CRUSH Map 中
# ceph osd crush remove osd.9
# ceph osd crush remove pc-amd64-100249[……]
「CEPH」- 运维管理：Monitor
增加 Monitor 实例（增）
WIP
删除 Monitor 实例（删）
WIP
修改 Monitor 实例（改）
WIP
查看 Monitor 实例（查）
# ceph mon stat
# ceph mon dump
epoch 3
fsid cf79beac-61eb-11ed-a2e0-080027d3c643
last_changed 2022-11-11T18:16:17.258788+0000
created 2022-11-11T18:08:21.534427+0000
min_mon_release 17 (quincy)
election_strategy: 1
0: [v2:192.168.200.1:3300/0,v1:192.168.200.1:6789/0] mon.ceph-node-01
1: [v2:192.168.200.2:3300/0,v1:192.168.200.2:6789/0] mon.ceph-node-02
2: [v2:192.168.200.3:3300/0,v1:192.168.200.3:6789/0] mon.ceph-node-03
dumped monmap epoch 3
// Client 将首选与 Leader Mon 建立连接，然后依照 rank 进行
# ceph quorum_status -f json-pretty[……]
「CEPH」- 运维管理：OSD
问题描述
该笔记将记录：在 Ceph Cluster 中，如何对 OSD 进行管理，以及相关问题的解决方案；
解决方案
OSD 维护是 Ceph Cluster 维护的常见任务；
增加 OSD 实例（增）
添加 OSD 实例
Ceph Documentation/OSD Service/CREATING NEW OSDS
# Tell Ceph to consume any available and unused storage device:
ceph orch apply osd –all-available-devices
# Create an OSD from a specific device on a specific host:
ceph orch daemon add osd *<host>*:*<device-path>*
# ceph osd tree
通过标志位，控制 OSD 行为
noout：该标志位将使 Ceph 集群不会将任何 OSD 标记为 out，无论其实际状态如何。这将会把所有的 OSD 保留在 Ceph 集群中； nodown：该标志位将使得 Ceph 集群不会将任何 OSD 标记为 down，无论其实际状态如何。这将会使集群中的所有 OSD 保持 UP 状态，而不会是 DOWN 状态； noup：该标志位将使得 Ceph 集群不会将任何 DOWN OSD 标记为 UP 状态。这样，任何被标记为 DOWN 的 OSD 都将只有在该标志位被清除以后，才会被标记为 UP。该标志位也会被用于新加入集群中的 OSD； noin：该标志位将使得 Ceph 集群不允许任何新的 OSD 加入集群。这在需要一次性加入多个 OSD 到集群中而不想它们自动地被加入集群时非常有用； norecover：该标志位将使得 Ceph 集群不做集群恢复（cluster recovery）； nobackfil1：该标志位将使得 Ceph 集群不做数据回填 (backfilling)。这在一次性加入多个 OSD 但是不想 Ceph 自动将数据分布到它们上时会非常有用； norebalance：该标志位将使得 Ceph 集群不做任何集群再平衡（cluster rebalancing )； noscrub：该标志位将使得 Ceph 集群不做 OSD 清理 （scrubbing）； nodeep-scrub：该标志位将使得 Ceph 不做 OSD 深度清理（deep scrubbing )； notieragent：该标志位将禁用缓存分层代理 （cache pool tiering agent)；
# ceph osd set noout
# ce[……]
「CEPH」- 集群的管理与运维
查看集群的运行状态
查看集群整体运行简况
# ceph -w
# ceph -s
# watch -n 1 ceph -s
# ceph status
cluster:
id: cf79beac-61eb-11ed-a2e0-080027d3c643
health: HEALTH_OK
services:
mon: 3 daemons, quorum ceph-node-01,ceph-node-02,ceph-node-03 (age 22h)
mgr: ceph-node-02.gktsek(active, since 22h), standbys: ceph-node-01.ymsncp
mds: 1/1 daemons up, 2 standby
osd: 6 osds: 6 up (since 22h), 6 in (since 22h)
data:
volumes: 1/1 healthy
pools: 5 pools, 113 pgs
objects: 67 objects, 107 MiB
usage: 20 GiB used, 160 GiB / 180 GiB avail
pgs: 113 active+clean
# ceph health
HEALTH_OK
// ——————————————————– // 如果集群存在问题，将显示相信信息
# ceph health detail
HEALTH_OK
查看存储空间使用情况
# ceph df
— RAW STORAGE —
CLASS SIZE AVAIL USED RAW USED %RAW USED
ssd 3.5 TiB 2.0 TiB 1.5 TiB 1.5 TiB 43.86
TOTAL 3.5 TiB 2.0 TiB 1.5 TiB 1.5 TiB 43.86
— POOLS —
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
device_health_metrics 1 1 101 MiB 31 303 MiB 0.04 223 GiB
vm-over-cephfs_data 14 32 0 B 0 0 B 0 223[……]
「CEPH」- 常见 PG 管理
增加 PG（增）
WIP
删除 PG（删）
WIP
修改 PG（改）
# 修复
# 需要结合当前状态使用，否则可能会影响用户数据；
ceph pg repair
# 清理
ceph pg scrub
# 深度清理
ceph deep-scrub
查看 PG（查）
# ceph pg ls
…
# ceph pg stat
641 pgs: 641 active+clean; 884 GiB data, 1.5 TiB used, 2.0 TiB / 3.5 TiB avail; 8.0 KiB/s rd, 3.4 MiB/s wr, 24 op/s
计算 PG 数量
Ceph: too many PGs per OSD – Stack Overflow
Total PGs Total PGs = (Total_number_of_OSD * 100) / max_replication_count This result must be rounded up to the nearest power of 2.
Total PGs per pool Calculation: Total PGs = ((Total_number_of_OSD * 100) / max_replication_count) / pool count This result must be rounded up to the nearest power of 2.
=
常见问题处理
… pg_num X size X would mean X total pgs, which exceeds max …
WIP
pg stuck in unknown state
故障：pg state unknown – 流年晕开时光 – 博客园
# ceph health detail
# ceph pg PG-ID query
// 如果数据不重要，进行强制修复
# ceph osd force-create-pg 3.1e
// 如果数据很重要，做好心里准备[……]
「Ceph」- 维护管理：Pool
创建存储池（增）
创建纠删码存储池
root@pc-amd64-100247:~# ceph osd dump | grep ensure
root@pc-amd64-100247:~# ceph osd erasure-code-profile set my-ec-testing rulesetfailure-domain=osd k=3 m=2
root@pc-amd64-100247:~# ceph osd erasure-code-profile ls
default
my-ec-testing
root@pc-amd64-100247:~# ceph osd pool create synology-nas-testing 16 16 erasure my-ec-testing
pool ‘synology-nas-testing’ created
删除存储池（删）
允许删除：
# ceph config set global mon_allow_pool_delete true
# ceph osd pool delete ‘pool name’ ‘pool name’ –yes-i-really-really-mean-it
// ——————————————————– // 或仅修改特定存储池，开启防止删除保护
# ceph osd pool get rbd nodelete
nodelete: false
# ceph osd pool set rbd nodelete 1
set pool 11 nodelete to 1
# ceph osd pool delete rbd rbd –yes-i-really-really-mean-it
Error EPERM: pool deletion is disabled; you must unset nodelete flag for the pool first
修改存储池（改）
修改 PG 数量
# ceph osd pool set cephfs_data pg_num 32
set pool 1 pg_num to 32
缩小副本数
[SOLVED] – change num-replicas on ceph rool online? | Proxmox Support Forum
ceph osd pool set POOL_NAME size 3
ceph osd pool set POOL_NAME min_size 2
// 缩小到 1 个副本
# ceph config set[……]
「CEPH」- 运维管理：RADOS
# ceph osd map rbd testfile
osdmap e595 pool ‘rbd’ (11) object ‘testfile’ -> pg
11.551a2b36 (11.6) -> up ([1,3,2], p1) acting ([1,3,2], p1)
# ceph osd primary-affinity 1 0.3 // 修改亲和属性，以将其他 OSD 作为 Primary OSD 设备
set osd.1 primary-affinity to 0.3 （8196602)
# ceph osd map rbd testfile // 再次查看，发现 osd.3 成为 testfile 的 Primary OSD 设备；
osdmap e597 pool ‘rbd’ (11) object ‘testfile’ -> pg
11.551a2b36 (11.6) -> up ([3,1,2], p3) acting ([3,1,2], p3)[……]
「Ceph」- 场景及方案
解决方案
操作对象
维护任务，针对 MON OSD MDS RGW 进行；
配置管理
在维护集群时，我们应该将 MON OSD MDS RGW 等等配置信息不断更新到配置文件中，这样便能够在一个节点中管理集群。
服务管理
通过 systemd 组件，来完成对 Ceph Cluster 管理
ceph daemon
ceph daemon 能够通过 .sock 连接 Ceph Cluster，并进行参数配置（临时修改）；
# ceph daemon osd.0 config get osd_recovery_max_chunk
ceph tell
类似 ceph tell 命令，也能够在运行时修改配置，并且不需要登录节点（即不依赖 .sock 文件，但是需要 MON 的配置）
# ceph tell osd.0 injectargs “–osd_recovery_threads=2”
REST API
Ceph 提供 REST API 进行服务管理，默认监听 5000 端口
[client.restapi]
keyring = ‘/path/to/keyring’
# ceph-rest-api
MON
添加/删除：https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/
删除节点，要确保集群的正常：
# ceph quorum_status –format jsno-pretty
# ceph mon stat
RGW
其添加需要额外的主机，并进行 Ceph 相关配置，该内容将在对象存储的学习过程中进一步讨论。[……]