It is a type of disk drive that integrates the drive controller directly on the drive itself.
SATA
参考文献
TechTerms/Hardware Terms/ATA Definition[……]
「ATA」- Advanced Technology Attachment
「AHCI」- 高级主机控制器接口（Advanced Host Controller Interface）
高级主机控制器接口（英文：Advanced Host Controller Interface，缩写：AHCI），是一种由英特尔制定的技术标准，它允许软件与 SATA 存储设备沟通的硬件机制，可让 SATA 存储设备激活高级 SATA 功能，例如原生指令队列及热插拔；
AHCI 详细定义一个存储器架构规范给予硬件制造商，规范如何在系统存储器与 SATA 存储设备间传输数据，（2014 年 3 月）最新 AHCI 规范为 1.3.1 版；
AHCI 模式则与 IDE 模式相反，装系统时需要安装 SATA 驱动
发展阶段
这在 HDD 时代，或者 SSD 早期，AHCI 协议和 SATA 接口足够满足系统性能需求，因为整个系统性能瓶颈在硬盘端（低速，高延时），而不是在协议和接口端。然而，随着 SSD 技术的飞速发展，SSD 盘的性能飙升，底层闪存带宽越来越宽，介质访问延时越来越低，系统性能瓶颈已经由下转移到上面的接口和协议处了。AHCI 和 SATA 已经不能满足高性能和低延时 SSD 的需求，因此 SSD 迫切需要自己更快、更高效的协议和接口；
AHCI and RAID
许多 SATA 设备控制器可个别激活 AHCI 功能或与 RAID 功能合并使用。英特尔就建议如果在其支持 AHCI 芯片组上使用 RAID 功能，采取 AHCI 模式组建 RAID 可以获得最大弹性，因为 AHCI 可在完成安装的操作系统中切换 RAID 组建模式；
参考文献
百度百科 /AHCI What is AHCI (Advanced Host Controller Interface)? | Definition from TechTarget NVME SAS SATA_yiyeguzhou100 的博客-CSDN 博客_nvme sas sata[……]
「DISK」- M.2 Interface
问题描述
规格尺寸
我们在买 M.2 SSD 的时候，商家都会说什么 SSD 是 2280 还是 2242 规格的，这里的规格实际上就是代表的 SSD 的尺寸大小；
M.2 模组的尺寸目前有 11 种，用 Type xxyy 的方式表示，xx 表示宽度，yy 表示长度，单位为毫米；
如图所示： 1）Type 2230，则表示其宽度 22nm，长度 30nm； 2）Type 2242，则表示其宽度 22mm，长度 42mm； 3）Type 2280，则表示其宽度 22nm，长度 80nm；
目前 M.2 SSD 常见的 Type 有三种：2230、2242、2280
接口类型
B-KEY and M-KEY
按照接口类型分，可以把 M.2 接口分为： 1）Socket 2 也可以叫做 B-KEY，支持 SATA，PCIE x2，其防呆键位于插槽的左方； 2）Socket 3 也可以叫做 M-KEY，支持 SATA，PCIE x4，其防呆键位于插槽的右方；
两种类型的插槽，其短边接脚数量有所差异。如下图为插槽：
下图为 M-KEY 接口：
B&M-KEY
起初，B-KEY 的只能插在 B-KEY（Socket 2）的接口中，M-KEY 的只能插在 M-KEY(Socket 3)的接口中， 但是，随着 M-KEY 接口的普及，越来越多电脑主板只有 M-KEY 接口，B-KEY 的 SSD 根本插不上去，
于是，厂商们又设计了一个 B&M-KEY 接口：
B&M-KEY 接口即可以插上 B-KEY，也可以插上 M-KEY；B&M-KEY 支持的通道和 B-KEY 支持的通道一样，都是 SATA PCIE x2；
B-KEY vs. M-KEY vs. B&M-KEY
B&M-KEY 可以兼容 M-KEY 和 B-KEY 两种，而 B-KEY 只能兼容 B-KEY 一种，这就导致 B-KEY 毫无优势，B-KEY 被 B&M-KEY 取代； 现在市面上：只有 B&M-KEY 和 M-KEY 两种 M.2 SSD 卖；B-KEY 的 M.2 SSD 已经绝迹；
SSD 的金手指有 B-KEY，M-KEY，B&M-KEY 三种，但是主板上的 M.2 接口只有 B-KEY 和 M-KEY 两种： 1）当主板上的 M.2 接口是 B-KEY 时，只能够插上 B&M-KEY 和 B-KEY 的 SSD，M-KEY 的插不上去； 2）当主板上的 M.2 接口是 M-KEY 时，只能够插上 B&M-KEY 和 M-KEY 的 SSD，B-KEY 的[……]
「Ceph」- Block Device（RBD，块存储）
块是一个有序字节，普通的一个块大小为 512 字节。基于块的存储是最常见的存储方式，比如常见的硬盘、软盘和 CD 光盘等，都是存储数据最简单快捷的设备；
解决方案
RBD 是 RADOS Block Device 的简称。RBD 块存储是 Ceph 提供的 3 种存储类型中使用最广泛、最稳定的存储类型；
原理简述
Ceph 块设备是一种精简置备模式，可以扩展大小且数据是以条带化的方式存储在一个集群中的多个 OSD 中，RBD 具有快照、多副本、克隆和一致性功能；
挂载的方式
RBD 块设备类似于磁盘，它可以挂载到物理机或虚拟机中，挂载的方式通常有以下两种； 1）Kernel 模块（简称 KRBD）方式； 2）利用 QEMU 模拟器通过 librbd 方式；
下面是 Ceph 块设备通过 Linux 内核模块或者 librbd 库与 OSD 之间交互通信的模式；
一般在为物理主机提供块设备时才使用 Kernel 的 RBD 模块，当 Ceph 块设备使用基于内核模块驱动时，可以使用 Linux 自带的页缓存（Page Caching）来提高性能；而为虚拟机（如
QEMU/KVM 类型）提供块设备时，通常是利用 Libvirt 调用 librbd 库的方式提供块设备，使用基于 librbd 的模块时可以使用 RBD 缓存（Cache）来提供性能；
特性特征
RBD 块设备用于虚拟机的系统卷、数据卷，根据 Ceph RBD 的分层（layering）功能，还可以方便实现基于 COW 的克隆技术，还有基于 RBD 的快照、导入、导出和扩容（Resizing）等功能；
应用场景
前面介绍了 RBD 基于 Kernel 和 librbd 库的使用，大多数使用场景中是基于 QEMU/KVM 通过 librbd 的方式；[……]
「Ceph」- 通过 Cephadm 部署 Ceph 服务（实验环境、测试目的）
版本历史
Name | Initial release | Latest | End of life (estimated)
Quincy 2022-04-19 17.2.0 2024-06-01
Pacific 2021-03-31 16.2.7 2023-06-01
Octopus 2020-03-23 15.2.15 2022-06-01
环境概述
Debian 11 (bullseye) ceph-node-01 192.168.200.1 172.31.252.201 2vCPU 2G 10G 10G ceph-node-02 192.168.200.2 172.31.252.202 2vCPU 2G 10G 10G ceph-node-03 192.168.200.3 172.31.252.203 2vCPU 2G 10G 10G
如果节点配置过低，可能会出现各种失败（诸如 服务进程调度失败、OSD 无法 up 状态 等等）；
流程概述
cephadm 通过 SSH 管理 Ceph-Cluster 的整个声明周期（可以通过 CLI 或 GUI 来管理） 1）从 Bootstrap 开始，现在单个节点上创建小型 Ceph-Cluster（one Monitor, one Manager） 2）然后通过编排接口来展开集群，添加更多的节点，并提供守护进程及服务；
#1 REQUIREMENTS
Python 3 Systemd Podman or Docker for running containers Time synchronization (such as chrony or NTP) LVM2 for provisioning storage devices
# install docker
# …
apt-get install python-is-python3
systemd –version # systemd 245 (245.4-4ubuntu3.17)
timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp true
apt-get install lvm2
#2 INSTALL CEPHADM
curl –silent –remote-name –location https://github.com/ceph/ceph/raw/quincy/src/cephadm/cephadm
chmod +x cephadm
./[……]
「ROOK-CEPH」- 安装仪表盘（Dashboard）
问题描述
该笔记将记录：部署 Ceph Dashboard 的方法，以对集群进行管理、监控等操作。
解决方案
诸如 PVE、Rook Ceph 等等，都使用 Ceph 服务，所以我们将分别讨论各种环境启用服务的方法；
for Proxmox VE
[TUTORIAL] – [Nautilus] activating CEPH DASHBOARD Ceph Dashboard — Ceph Documentation
apt-get install ceph-mgr-dashboard # 需要在每个节点中执行
# 配置 TLS 信息
ceph config set mgr mgr/dashboard/ssl false # 我们选择禁用
# 创建管理用户
ceph dashboard ac-user-create admin administrator -i /tmp/password
# 查看访问地址
ceph mgr services
# 浏览器访问：8080 for HTTP, 8443 for HTTPS
…
for Rook Ceph
参考 Rook Ceph Documentation/Ceph Dashboard 文档，以获取详细说明；
服务开启
我们通过 Rook Ceph 的 Helm Chart 进行部署，所以该部分描述的配置方法与此部署方式相关；
rook-ceph-cluster.helm-values.yaml
…
cephClusterSpec:
dashboard:
enabled: true
…
ingress:
dashboard:
annotations:
cert-manager.io/cluster-issuer: letsencrypt
nginx.ingress.kubernetes.io/backend-protocol: “HTTPS”
nginx.ingress.kubernetes.io/server-snippet: |
proxy_ssl_verify off;
host:
name: ceph-dashboard.example.com
tls:
– hosts:
– ceph-dashboard.example.com
secretName: ceph-dashboard
ingressClassName: nginx
…
用户登录
#[……]
「CEPH」- 性能测试：测试磁盘性能
解决方案
补充说明：需要对在集群中的每个用于 Ceph 存储的块设备进行测试，并记录结果。鉴于我们使用相同规格的硬盘，所以可以无需针对每个块存储进行测试。但是，同时测试这些磁盘的性能会得到不同的性能表现，所以我们仍旧建议针对这些磁盘同时进行性能测试。
Bandwidth
fio –name=write_bandwidth_test \
–filename=/dev/sdc –filesize=29313144Ki \
–time_based –ramp_time=2s –runtime=1m \
–ioengine=libaio –direct=1 –verify=0 –randrepeat=0 \
–bs=1M –iodepth=64 –rw=write –numjobs=16 –offset_increment=1832071Ki –group_reporting
// 经过 5+ 轮测试：min(bandwidth) == 13MBPS; max(bandwidth)==24MBPS;
fio –name=read_bandwidth_test \
–filename=/dev/sdc –filesize=29313144Ki \
–time_based –ramp_time=2s –runtime=1m \
–ioengine=libaio –direct=1 –verify=0 –randrepeat=0 \
–bs=1M –iodepth=64 –rw=read –numjobs=4 –thread –offset_increment=1832071Ki
// 经过 5+ 轮测试：min(bandwidth) == 88.9MBPS; max(bandwidth) == 90.5MBPS;
IOPS
fio –name=write_iops_test \
–filename=/dev/sdc –filesize=29313144Ki \
–time_based –ramp_time=2s –runtime=1m \
–ioengine=libaio –direct=1 –verify=0 –randrep[……]
「CEPH」- 性能测试：测试网络性能
Bandwidth
网络吞吐是另外一个重要的指标。可以使用 iperf 进行测试，它通过创建 Server/Client 连接进行 TCP 与 UDP 的吞吐测试；
使用方法相较简单：需要两台机器，分别是 Client 与 Server：
# 在 Server 上
iperf3 -s -p 6900
# 在 Client 上
# 当命令执行结束时，将显示网络最大吞吐；
# iperf3 -p 6900 -c 172.31.253.240
Connecting to host 172.31.253.240, port 6900
[ 5] local 172.31.253.248 port 38848 connected to 172.31.253.240 port 6900
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 956 Mbits/sec 0 413 KBytes
[ 5] 1.00-2.00 sec 109 MBytes 919 Mbits/sec 16 499 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 927 Mbits/sec 0 499 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 499 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 943 Mbits/sec 0 499 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 943 Mbits/sec 0 499 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 499 KBytes
[ 5] 7.00-8.00 sec 113 MBytes 945 Mbits/sec 0 619 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 619 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 931 Mbits/sec 0 619 KB[……]
「Ceph」- 块存储（学习笔记）
RBD, RADOS Block Device
第一步、配置客户端
检查内核模块
检查 Kernel 具有 rbd 模块：如下命令若无输出则表示模块已加载
server> modprobe rbd
RHEL 6.x、CentOS 6.x 等低版本内核的 Linux 操作系统，其内核中默认没有集成 RBD 驱动，RHEL 7.x、CentOS 7.x、Ubuntu14.04 及其他 Linux 衍生版本带有 3.10.x 内核的操作系统中已经默认集成了 RBD 驱动。RBD 的使用依赖内核版本，为了提高性能和避免 Bug，建议内核版本不小于 3.10；
配置认证信息
Ceph 提供认证，其要求 Client 必须具有凭证与权限，以此才能访问存储；
Ceph 默认创建 client.admin 用户，该用户具有足够的权限，但是我们这里将演示如何创建独立的用户：
server> ceph auth get-or-create client.rbd mon ‘allow r’ osd ‘allow class-read object_prefix rbd_children, allow rwx pool=rbd’
[client.rbd]
key = AQBAO29jy4slJhAA+eUkcCRKjKo08uBb8G63IQ==
server> ceph auth get-or-create client.rbd | ssh root@172.31.252.100 tee /etc/ceph/ceph.client.rbd.keyring
client> cat /etc/ceph/ceph.client.rbd.keyring >> /etc/ceph/keyring
在后续的测试中，我们发现，如果重启系统，将无法继续挂载 RBD 镜像：
// 并提示如下错误：
…
Sep 6 12:52:33 n01 kernel: [ 875.165082] rbd: rbd0: blacklist of client2508785 failed: -13
Sep 6 12:52:33 n01 kernel: [ 875.165082] rbd: rbd0: failed to acquire lock: -13
Sep 6 12:52:33 n01 kernel: [ 875.165355] rbd: rbd0: no lock owners detected
…
// 解决方案
// 这可能与认证配置相关，后面将进一步讨论
ceph auth caps client.n01 mon ‘profile[……]
「Ceph」- 块存储 克隆（Clone）
解决方案
Ceph 支持从 Snapshot 创建 Clone，其被称为快照分层（Snapshot Layering）。虽然 Snapshot 是只读的，但是 COW Clone 是可写的。
Ceph RBD Image 有两种： 1）format 1：默认 Image 格式； 2）format 2：COW 仅支持 Format 2 的 RDB Image；
配置案例
// 创建存储
# rbd create rbd2 –size 10240 –image-feature layering –name client.rbd
# rbd info –image rbd2 –name client.rbd
// 创建快照
// 并保护快照，否则破坏快照将导致其他克隆无法使用；
# rbd snap create rbd/rbd2@snapshot_for_cloning –name client.rbd
# rbd snap protect rbd/rbd2@snapshot_for_cloning –name client.rbd
// 创建克隆
# rbd clone <pool-name>/<parent-image-name>@<snap-name> <pool-name>/<child_image-name> –image-feature <feature-name>
# rbd clone rbd/rbd2@snapshot_for_cloning rbd/clone_rbd2 –image-feature layering –name client.rbd
// 查看信息
// 在镜像信息中，将包含父镜像相关的信息
# rbd info rbd/clone_rbd2 –name client.rbd
// 摆脱父镜像，实现完整克隆
// 之后，可以考虑移除父镜像
# rbd flatten rbd/clone_rbd2 –name client.rbd
# rbd info –image clone_rbd2 –name client.rbd
# rbd snap unprotect rbd/rbd2@snapshot_for_cloning –name client.rbd
# rbd snap rm rbd/rbd2@snapshot_for_cloning –name client.rbd[……]
「Ceph」- 块存储 快照（Snapshot）
创建快照：
# rbd snap create <pool name>/<image name>@<snap name>
# rbd snap create rbd/rbd1@snapshot1
删除快照：
# rbd snap rm <pool-name>/<image-name>@<snap-name>
# rbd snap rm rbd/rbd1@snapshot1 –name client.rbd
// 删除所有快照
# rbd snap purge <pool-name>/<image-name>
# rbd snap purge rbd/rbd1 –name client.rbd
修改快照：
# rbd snap rename <pool-name>/<image-name>@<original-snapshot-name> <pool-name>/<image-name>@<new-snapshot-name>
# rbd snap rename rbd/rbd1@snapshot1 rbd/rbd1@snapshot1_new
查看快照：
# rbd snap ls <pool name>/<image name>
# rbd snap ls rbd/rbd1
从快照恢复数据：
# rbd snap rollback <pool-name>/<image-name>@<snap-name>
# umount /mnt/ceph-disk1
# rbd snap rollback rbd/rbd1@snapshot1 –name client.rbd[……]
「Ceph」- 部署 CephFS（文件系统）
解决方案
第一步、运行 mds 服务
for ceph-node-01
# ceph fs volume create <fs_name> –placement=”<placement spec>”
# ceph fs volume create foo-fs –placement=”ceph-node-01 ceph-node-02 ceph-node-03″
# ceph mds stat
foo-fs:1 {0=foo-fs.ceph-node-03.lcyldy=up:active} 2 up:standby
# ceph fs ls
name: foo-fs, metadata pool: cephfs.foo-fs.meta, data pools: [cephfs.foo-fs.data ]
第二步、创建 Keyring 文件
for ceph-node-0
# ceph auth get-or-create client.cephfs -o /etc/ceph/client.cephfs.keyring \
osd ‘allow rwx pool=cephfs.foo-fs.meta,allow rwx pool=cephfs.foo-fs.data’ \
mon ‘allow r’ \
mds ‘allow r’
# cat /etc/ceph/client.cephfs.keyring
[client.cephfs]
key = AQDunnxjNd/fMxAAR0KPJ+TROGLIPGRN9sLnAw==
第三步、客户端挂载访问
# mount -t ceph -o ‘name=cephfs,secretfile=/path/to/secretfile’ …
mount -t ceph -o ‘name=cephfs,secret=AQDunnxjNd/fMxAAR0KPJ+TROGLIPGRN9sLnAw==’ 192.168.200.3:6789:/ /mnt/ce[……]
「Ceph」- CephFS 转 NFS（通过 NFS 访问 CephFS 存储）
问题描述
NFS-Ganesha 是个 NFS Server 的实现，它运行在用户态空间，它具有的一个功能是：支持 CephFS FSAL（File System Abstraction Layer，文件系统抽象层）特性，其利用 libcephfs 库，将 CephFS 重新导出为 NFS 服务；
NFS 是类 UNIX 系统中最流行的网络共享文件系统之一，如此即使是不支持 CephFS 文件系统的类 UNIX 系统，也可以通过 NFS 来访问 Ceph 文件系统；
解决方案
for Debian 11 (bullseye)
apt-get install -y nfs-ganesha nfs-ganesha-ceph
systemctl enable rpcbind.service && systemctl start rpcbind.service
cat > /etc/ganesha/ganesha.conf <<EOF
EXPORT {
Export_ID = 1;
Path = “/”;
Pseudo = “/”;
Access_Type = RW;
NFS_Protocols = “3”;
Squash = No_Root_Squash;
Transport_Protocols = TCP;
SecType = “none”;
FSAL {
Name = CEPH;
}
}
EOF
systemctl restart nfs-ganesha.service
systemctl status nfs-ganesha.service
# showmount -e 127.0.0.1
Export list for 127.0.0.1:
/ (everyone)
Q：为什么不需要在 NFS Ganesha 中进行与 Ceph 相关的配置？ A：演示目的，我们 NFS Ganesha 直接部署在 Ceph Node 中，所以 NFS Ganesha 能够找到 Ceph 默认配置信息；[……]
「CephFS」- 挂载
for Rook Ceph
如果想要查看共享文件系统中的数据，我们应该怎么查看呢？
本文将介绍如何在 Rook-Ceph 之上创建共享文件系统；
首先，安装 Rook Toolbox 工具。
然后，进入容器执行，执行如下命令：
# Create the directory
mkdir -pv /tmp/registry
# Detect the mon endpoints and the user secret for the connection
mon_endpoints=$(grep mon_host /etc/ceph/ceph.conf | awk ‘{print $3}’)
my_secret=$(grep key /etc/ceph/keyring | awk ‘{print $3}’)
# Mount the file system
mount -t ceph -o mds_namespace=myfs,name=admin,secret=$my_secret $mon_endpoints:/ /tmp/registry
# See your mounted file system
df -h
参考文献
GitHub/rook/Documentation/ceph-filesystem.md ROOK/Documentation/Ceph Storage/Shared File System Direct Tools/Shared Filesystem Tools[……]
「Ceph」- 在特定的 OSD 上创建 Pool 实例
问题描述
在 Cpeh Cluster 中，即存在 SSD 磁盘，又存在 HDD 磁盘，能够同时作为 OSD 并为 Pool 提供存储。
我们并不希望两者混用，我们希望能够分开：部分 Pool 使用 SSD 存储，部分 Pool 使用 HDD 存储；
该笔记将记录：在 Ceph 中，如何为 Pool 使用 SSD 存储（或 HDD 存储）；
解决方案
为解决该问题，需要修改 Ceph CRUSH map 内容
1）通过 CRUSH map 来创建不同的 Rule， 2）并为 Pool 指定其所使用的 Rule；
第一步、获取 CRUSH Map 内容
…
第二步、修改 CRUSH Map 内容
在 CRUSH Map 中，增加 Bucket 定义：
root ssd {
id -1
alg straw
hash 0
item osd.0 weight 0.010
item osd.2 weight 0.010
item osd.3 weight 0.010
}
root hdd {
id -6
alg straw
hash 0
item osd.0 weight 0.010
item osd.2 weight 0.010
item osd.3 weight 0.010
}
在 CRUSH Map 中，增加 Rule 定义：
rule ssd-pool {
ruleset 1
type replicated
min_size 1
max_size 10
step take ssd
step chooseleaf firstn 0 type osd
step emit
}
rule hdd-pool {
ruleset 6
type replicated
min_size 1
max_size 10
step take hdd
step chooseleaf firstn 0 type osd
step emit
}
第三步、更新 CRUSH Map 内容
…
第四步、验证配置是否生效
# ceph osd tree
… 能够看到新的 OSD Tree，分别是 ssd 与 hdd 两个结构；
// 创建 Pool 使用 SSD 并验证其所使用的 Rule；
# ceph pool create pool-in-ssd 8 8
# ceph osd pool set pool-in-ssd crush[……]
「FastDFS」- 开源、轻量、分布式文件系统
FastDFS，使用 C 语言开发的一项开源轻量级分布式文件系统；
解决方案
解决大容量存储和负载均衡的问题
特性特征
文件存储、文件同步、文件访问（文件上传、文件下载） 冗余备份、负载均衡、线性扩容、高可用、高性能
应用场景
特别适合以文件为载体的在线服务，如相册网站、视频网站等等；
参考文献
CSDN/FastDFS 简介[……]
「FastDFS」- 概念与架构
服务的组成部分
客户端（Client），跟踪器（Tracker），存储节点（Storage）
客户端（Client）
Client 访问 Tracker，进行文件管理操作。
跟踪器（Tracker）
主要做调度工作，负责管理Storage与Group，可以由单台或多台服务器构成，在访问上起负载均衡的作用。可随时增加或减少，并且不会影响业务。有服务器都是对等的，可以根据服务器的负载情况随时增加或减少。
每个storage在启动后会连接Tracker，告知自己所属的group等信息，并保持周期性的心跳，tracker根据storage的心跳信息，建立group==>[storage server list]的映射表，Tracker需要管理的元信息很少，会全部存储在内存中；另外tracker上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数据，这样使得tracker非常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，Tracker cluster里每个tracker之间是完全对等的，所有的tracker都接受stroage的心跳信息，生成元数据信息来提供读写服务。
存储节点（Storage）
存储节点都可以由单台或多台服务器构成。存储节点均可动态增加或减少，并且不会影响业务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。
存储文件，完成文件管理的所有功能，就是这样的存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key valuepair）方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。
为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。
在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。
当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。
Storage采用了分卷[Volume]（或分组[group]）的组织方式，存储系统由一个或多个组组成，组与组之间的文件是相互独立的，所有组的文件容量累加就是整个存储系统中的文件容量。一个卷[V[……]
「FastDFS」- 安装及部署（单机）
环境概述
属性
参数
操作系统
Kali GNU/Linux Rolling
软件版本
FastDFS V6.06
第一步、安装服务
### 安装 libfastcommon 类库
git clone https://github.com/happyfish100/libfastcommon.git
cd libfastcommon; git checkout V1.0.43
./make.sh clean && ./make.sh && ./make.sh install
### 安装 fastdfs 服务
git clone https://github.com/happyfish100/fastdfs.git
cd fastdfs; git checkout V6.06
./make.sh clean && ./make.sh && ./make.sh install
### 安装配置文件
./setup.sh /etc/fdfs
第二步、修改配置
修改数据存储目录
配置文件使用 /home/yuqing/ 目录，可以根据需要调整：
mkdir -pv /srv/fastdfs/
sed -i ‘s%/home/yuqing/%/srv/%g’ /etc/fdfs/*
修改 tracker 地址
修改 /etc/fdfs/storage.conf 的 tracker_server 配置，根据需要设置正确地址：
tracker_server = host:port
第三步、启动服务
由于系统使用 systemd 管理服务，但是源码包里提供启动脚本不适用。执行如下命令启动服务：
#!/bin/sh
/etc/init.d/fdfs_trackerd start
/etc/init.d/fdfs_storaged start
# 或者
/usr/bin/fdfs_trackerd /etc/fdfs/tracker.conf start
/usr/bin/fdfs_storaged /etc/fdfs/storage.conf start
（可选）运行监控程序
#!/bin/sh
/usr/bin/fdfs_monitor /etc/fdfs/client.conf
第四步、测试服务可用
#!/bin/sh
/usr/bin/fdfs_test /[……]
「Storage OS」- 用作存储的操作系统
问题描述
该笔记将记录：我们知道和使用的存储操作系统，以及常见问题的解决方案。
解决方案
Open Media Vault（based on Debian）
openmediavault – The open network attached storage solution Installation — openmediavault 5.x.y documentation
Open Meida Vault，作为存储管理系统。我们能够方便的创建 NFS、SMB、FTP 等等共享。
# 04/06/2021 我们首次安装，下面是我们在初次体验后的直观感受： 1）
XigmaNAS (based on FreeBSD)
XigmaNAS – Wikipedia XigmaNAS – XigmaNAS
XigmaNAS is a continuation of the original FreeNAS code, which was developed between 2005 and late 2011 It was released under the name NAS4Free on 22 March 2012. The name was changed to XigmaNAS in July 2018
相关文档： Install and Configure XigmaNAS NAS (Network-Attached Storage) Solution | ComputingForGeeks
# 03/28/2022 我们首次安装，下面是我们在初次体验后的直观感受： 1）缺：图形界面老派风格（与其他同类产品相比），不如其他产品华丽； 2）优：专注于存储功能，没有多余的、非存储相关的附加特性； 3）优：有 Syncthing 模块，这是我们需要的功能；
TrueNAS CORE（previously FreeNAS, based on FreeBSD）
https://www.truenas.com/ TrueNAS Core 12 Install and Basic Setup – YouTube
ESOS, Enterprise Storage OS（based on the SCST project）
https://en.wikipedia.org/wiki/Enterprise_Storage_OS http://www.esos-project.com
A text-based user interface (TUI)
Rockstor（based on CentOS）
Rockstor | Linux & BTRFS p[……]
「Open Media Vault」- 存储管理系统
问题描述
该笔记将记录：如何安装及使用 openmediavault 存储管理系统，以及相关问题的解决方案（常见问题处理）；
解决方案
# 05/24/2021 我们选择 openmediavault 是因为：我们还需要在该存储主机中部署其他服务，而其基于 Debian 发行版将为此提供便利；[……]
「Open Media Vault」- 系统安装
解决方案
安装方法与 Debian 类似（详细参考 Installation using an ISO image 文档）：
# 制作：创建 USB 启动盘
dd if=openmediavault_5.5.11-amd64.iso of=/dev/sdX bs=4096
# 安装：与 Debian 相同
# …
# 访问：两种方式
# SSH：root / <password>（在安装时设置的密码）
# Web：admin / openmediavault（默认帐号密码）
常见问题处理
Q：查看当前版本？ A：Web GUI / Diagnostics / Dasboard / System Information，或者 dpkg -l | grep -i “openmediavault -” How can I find out what version of OMV is running on my server – General – openmediavault
Q：服务升级流程？ A：Software — openmediavault 5.x.y documentation
参考文献
5 Best Free and Open source NAS Software for Linux – Linux Hint 8 Best Free and Open source NAS or SAN software -H2S Media openmediavault – The open network attached storage solution[……]
「Open Media Vault」- 常见问题处理
安装扩展
openmediavault/stable/Plugins
参考 openmediavault/stable/Plugins 文档，以获取关于插件的详细说明；
添加第三方插件库
openmediavault/OMV-Extras.org Plugin/Guides
官方自带插件数量较少，我们需要第三方插件仓库：
1）参考 start [omv-extras.org] 文档，以获取安装方法；
# For OMV 6.x (shaitan)
wget -O – https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install
chmod +x install
./install -n
2）当安装成功后，在菜单栏中，将看到 System / omv-extras 菜单项；
openmediavault-filebrowser
Plugins/File Browser plugin error when enabling
该插件将 Web File Browser 集成到 OMV 中，以提供文件浏览服务
当插件安装后，其默认以 Podman 运行： 1）需要修改 Podman infra_image 地址，否则服务无法启动；[……]
「OpenMediaVault」- 常见问题处理
DMAR: DRHD: handling fault status reg 3
[SOLVED] “kernel: DMAR: DRHD: handling fault status reg 3″ / Kernel & Hardware / Arch Linux Forums
问题描述
…
[ 11.552385] NFSD: starting 90-second grace period (net f0000000)
[ 17.365444] DMAR: DRHD: handling fault status reg 3
[ 17.365483] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault addr 0xff965000 [fault reason 0x06] PTE Read access is not set
[ 17.385665] DMAR: DRHD: handling fault status reg 3
[ 17.385701] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault addr 0xff95f000 [fault reason 0x06] PTE Read access is not set
[ 17.457286] DMAR: DRHD: handling fault status reg 3
[ 17.457331] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault addr 0xff936000 [fault reason 0x06] PTE Read access is not set
[ 17.458909] DMAR: DRHD: handling fault status reg 3
…
解决方案
# vim /etc/default/grub
…
GRUB_CMDLINE_LINUX_DEFAULT=”intel_iommu=off”
…[……]
「fio」- 学习笔记
问题描述
我们需要针对硬盘进行性能测试，而 fio 又是个广泛应用的工具，所以我们将学习其使用方法；
在学习的过程中：（1）我们将围绕官方文档展开学习，并记录我们感兴趣的内容；（2）学习使用 fio 进行存储性能测试；（3）尝试学习并理解 fio 的实现原理，以更好理解性能测试结果；
该笔记将记录：我们在 fio 的学习过程中产生的笔记、实践经验、相关问题的解决办法；[……]
「fio」- 针对官方文档的快速阅读
问题描述
该笔记将记录：我们在快速阅读 fio 官方文档时产生的学习笔记，其内容来源是对官方文档的摘录，其内容主题是我们需要关注的地方；
解决方案
为了少打字，我们直接机翻或者复制英语原句；
fio – Flexible I/O tester rev. 3.32
1.1. Overview and history
作者需要一种能够模拟给定 I/O 工作负载的工具，而无需一次又一次地编写定制的测试用例。（1）可以涉及任意数量的进程或线程，并且每个进程或线程都可以使用自己的方式生成 I/O。（2）您可能让某人弄脏内存映射文件中的大量内存，或者可能有多个线程使用异步 I/O 发出读取；
fio 需要足够灵活以模拟这两种情况，以及更多情况。Fio 生成许多线程或进程来执行用户指定的特定类型的 I/O 操作。fio 有一些全局参数，每个参数都由线程继承，除非另外给它们的参数覆盖了给定的设置。fio 的典型用途是编写一个与要模拟的 I/O 负载相匹配的作业文件；
1.2. Source
暂时略过此部分内容，将来有需要时再进一步深入……
1.3. Mailing list
暂时略过此部分内容，将来有需要时再进一步深入……
1.4. Author
暂时略过此部分内容，将来有需要时再进一步深入……
1.5. Maintainers
暂时略过此部分内容，将来有需要时再进一步深入……
1.6. Binary packages
暂时略过此部分内容，将来有需要时再进一步深入……
1.7. Building
暂时略过此部分内容，将来有需要时再进一步深入……
我们直接使用 Linux 提供的二进制程序进行 fio 学习，暂时不需要我们自己完成构建；
1.7.1. Windows
暂时略过此部分内容，将来有需要时再进一步深入……
1.7.2. Documentation
暂时略过此部分内容，将来有需要时再进一步深入……
1.8. Platforms
我们主要在[……]
「fio」- 输出内容解释
问题描述
官方文档已解释 fio 的输出内容，我们也完成学习，但是我们并没有记住；
所以，我们将再次学习 fio 输出的内容（各个字段的含义），并记录该笔记；
该笔记将记录：fio 输出内容的含义，核心目的是便于以后的快速查阅；
解决方案
针对输出内容的详细解释，建议 fio/1.15. Interpreting the output 文档，该笔记仅记录我们需要关注的内容；
运行时，状态输出
Jobs: 20 (f=20): [R(10),W(10)][4.0%][r=20.5MiB/s,w=23.5MiB/s][r=82,w=94 IOPS][eta 57m:36s]
| |-+–| |—–+—–||-+–||———–+———–||——+——-||—–+—–|
| | | | | | |
| | | | | | 剩余运行时间；
| | | | | r/w IOPS；
| | | | r/w Bandwidth；
| | | 预计完成百分比；
| | |
| | 10 个 Job 在进行 Read；10 个 Job 在进行 Write 操作；
| |
| 已打开 20 个文件；
|
正在运行并执行 IO 的进程数；
运行后，报告输出
输出概览（Overview）
Client1: (groupid=0, jobs=1): err= 0: pid=16109: Sat Jun 24 12:07:54 2017
write: IOPS=88, BW=623KiB/s (638kB/s)(30.4MiB/50032msec)
slat (nsec): min=500, max=145500, avg=8318.00, stdev=4781.50
clat (usec): min=170, max=78367, avg=4019.02, std[……]
「fio」- Measurements and reporting（控制报告输出）
常见问题处理
在日志中，IOPS 全部为 1
IOPS logs shows only 1 · Issue #385 · axboe/fio
Fio defaults to logging every I/O not averaging them out over a period. See the Log File Formats section of the HOWTO for further details. You can use log_avg_msec to change this behaviour.
通过 log_avg_msec 选项，来聚合 IOPS 数据，而非记录每条数据；
参考文献
fio 3.33 documentation/1.13.19. Measurements and reporting[……]
「fio」- 块存储，性能测试
环境准备工作
磁盘填充测试数据
Q：为什么要进行数据填充？ A：针对空块与含数据的块，当从两者中读取数据读时，将会得到不同的性能结果。所以为使结果更加准确，我们将对块设备进行数据填充；
fio –name=fill_disk \
–filename=/dev/sdc –filesize=29313144Ki \
–ioengine=libaio –direct=1 –verify=0 –randrepeat=0 \
–bs=128K –iodepth=64 –rw=randwrite
# 该命令参数将完成数据填充的任务。鉴于其参数并不符合性能测试要求，所以我们不无需关注其输出的报告；
存储测试配置信息
命令选项如下，其为各个测试场景中的通用选项：
–filename=/dev/sdc：物理磁盘路径：/dev/sdc –filesize=29313144Ki：我们的磁盘大小，30016659456 / 1024 = 29313144Ki (~28G)
–time_based：基于时间来进行基准测试，即任务仅云新特定时间； –runtime=1m：测试任务仅运行一分钟，得到测试结果即可，无需长时间运行； –ramp_time=2s：当使得性能趋于稳定后，再输出性能测试结果（在 2s 后）；
–ioengine=libaio：使用异步 IO 引擎，以模拟更多负载； –direct=1：使用 non-buffered I/O，将数据直接写入物理磁盘。 –verify=0：无需要对写入的数据进行验证 –randrepeat=0：随机产生数据；
Bandwidth（带宽）
–bs=1M：块大小对带宽的测试结果是有影响的，具体块大小取决于业务场景； –iodepth=64：需要足够的 I/O depth，以产生足够多个 IO 负载，我们这里 I/O depth 为 64； –rw=write：需要通过 Seq. r/w 来实现带宽测试，而 Rnd. r/w 将消耗更多时间进行寻道，进而无法得到准确的结果； –numjobs=16：需要创建多个进程，以产生足够多的 IO 负载，我们这里创建 16 个进程； –offset_increment=1832071Ki：将文件分为 16 部分（29313144÷16），使得每个进程仅写入自己所属的部分； –group_reporting，能够将多个进程的输出结果进行聚合显示，而非显示每个进程的测试报告；
写入带宽（Seq. Bandwidth）
fio –name[……]
「fio」- 文件系统，性能测试
解决方案
针对文件系统的性能测试，与针对块存储的性能测试，两者相仿，其主要差异在于数据读写方式。
Bandwidth（带宽）
–bs=1M：使用 1MB 的 I/O 块大小 –iodepth=64：至少 64 的 I/O 深度 –numjobs=16：通过使用多个并行流 (16+) 执行顺序写入来测试写入吞吐量； –rw=write：通过 Seq. Write 进行写入带宽测试；通过 Seq. Read 进行读取带宽测试；
写入带宽（Seq. Bandwidth）
fio –name=write_throughput \
–directory=/tmp/fio/ –size=10G \
–time_based –runtime=60s –ramp_time=2s \
–ioengine=libaio –direct=1 –verify=0 \
–bs=1M –iodepth=64 –numjobs=16 –rw=write –group_reporting=1
读取带宽（Rnd. Bandwidth）
fio –name=read_throughput \
–directory=/tmp/fio/ –size=10G \
–time_based –runtime=60s –ramp_time=2s \
–ioengine=libaio –direct=1 –verify=0 \
–bs=1M –iodepth=64 –numjobs=16 –rw=read –group_reporting=1
IOPS（每秒 IO 数）
–rw=randwrite：通过执行 Rnd. Write 来测试写入 IOPS；通过执行 Rnd. Read 来测试读取 IOPS； –bs=4K：使用 4 KB 的 I/O 块大小 –iodepth=256：至少 256 的 I/O 深度：
写入次数（Rnd. IOPS）
fio –name=write_iops \
–directory=/tmp/fio/ –size=10G[……]