本章提供可帮助您增强 Ceph 集群性能的信息,以及有关如何设置集群的提示。
要识别可能处于孤立状态的日志/WAL/DB 设备,请执行以下步骤:
选择可能存在孤立分区的设备,并将其分区列表保存到文件中:
root@minion >
ls /dev/sdd?* > /tmp/partitions
针对所有 block.wal、block.db 和日记设备运行 readlink
,并将输出与之前保存的分区列表进行比较:
root@minion >
readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
| sort | comm -23 /tmp/partitions -
输出内容为 Ceph 未使用的分区列表。
使用您首选的命令(例如 fdisk
、parted
或 sgdisk
)删除不属于 Ceph 的孤立分区。
默认情况下,Ceph 每天会执行一次浅层洗刷(请参见第 9.6 节 “洗刷”了解详细信息),每周会执行一次深层洗刷。浅层洗刷会检查对象大小及校验和,以确保归置组存储的是相同的对象数据。深层洗刷会检查对象的内容及其副本,以确保实际内容相同。在洗刷期间检查数据完整性会增加集群上的 I/O 负载。
默认设置允许 Ceph OSD 在不合适的时间(如负载较重时)启动洗刷。当洗刷操作与客户操作发生冲突时,可能会出现延迟和性能不佳情况。Ceph 提供了数个洗刷设置,可将洗刷限制在低负载或非高峰时段执行。
如果集群在日间负载高而在夜间负载低,请考虑将洗刷限制在夜间执行,例如在晚上 11 点到早上 6 点期间执行。
[osd] osd_scrub_begin_hour = 23 osd_scrub_end_hour = 6
如果使用时间限制无法有效决定洗刷时间表,请考虑使用 osd_scrub_load_threshold
选项。其默认值为 0.5,但也可针对低负载情况进行相应调整:
[osd] osd_scrub_load_threshold = 0.25
进行定期维护时,您可能需要停止 OSD。如果您不希望 CRUSH 自动重新平衡集群,以免出现大量数据传输,请先将集群设为 noout
:
root@minion >
ceph osd set noout
当集群设为 noout
时,您便可开始在需要执行维护工作的故障域中停止 OSD:
root@minion >
systemctl stop ceph-osd@OSD_NUMBER.service
有关详细信息,请参见第 5.1.2 节 “启动、停止和重启动个别服务”。
完成维护工作后,再次启动 OSD:
root@minion >
systemctl start ceph-osd@OSD_NUMBER.service
OSD 服务启动后,取消集群的 noout
设置:
cephadm@adm >
ceph osd unset noout
Ceph 要求所有节点之间的时间都保持精确同步。
建议将所有 Ceph 集群节点与内部网络上至少三个可靠时间源进行同步。内部时间源可指向公共时间服务器,或使用自己的时间源。
不要将所有 Ceph 集群节点直接与远程公共时间服务器同步。如果采用这种配置,集群中的每个节点都会借助自己的 NTP 守护进程通过因特网持续与三到四台时间服务器通讯,而这些服务器提供的时间可能会稍有不同。此解决方案在很大程度上带来了延迟方面的变数,使得难以甚至无法将时钟偏差保持在 0.05 秒以下(Ceph monitor 要求这种精度)。
有关如何设置 NTP 服务器的详细信息,请参见《SUSE Linux Enterprise Server 管理指南》。
要更改集群上的时间,请执行以下操作:
您可能会遇到需要将时间往回调的情况,例如,当时间从夏令时改成标准时间时就需要如此。不建议将时间回调的幅度超过集群的关闭时长。将时间往前调不会造成任何问题。
停止正在访问 Ceph 集群的所有客户端,尤其是使用 iSCSI 的客户端。
关闭 Ceph 集群。在每个节点上,运行:
root #
systemctl stop ceph.target
如果您使用了 Ceph 和 SUSE OpenStack Cloud,则还需停止 SUSE OpenStack Cloud。
确认 NTP 服务器的设置是否正确,即所有 chronyd
守护进程是否可从本地网络中的一个或多个时间源获取时间。
在 NTP 服务器上设置正确的时间。
确认 NTP 正在运行且在正常工作,然后在所有节点上运行:
root #
systemctl status chronyd.service
启动所有监视节点,并校验是否不存在时钟偏差:
root #
systemctl start target
启动所有 OSD 节点。
启动其他 Ceph 服务。
启动 SUSE OpenStack Cloud(如果有)。
如果数据均衡写入 OSD,则认为集群是平衡的。集群中的每个 OSD 都分配了权重。权重是一个相对数字,告知 Ceph 应写入相关 OSD 的数据量。权重越高,要写入的数据就越多。如果 OSD 的权重为零,则不会向其写入任何数据。如果某个 OSD 的权重相对于其他 OSD 而言较高,则大部分数据将会写入这个 OSD,致使集群变得不平衡。
不平衡集群的性能较差;如果某个权重较高的 OSD 突然崩溃,则大量的数据就需要转移到其他 OSD,这也会导致集群速度变慢。
为避免此问题,应该定期检查 OSD 中的数据写入量。如果写入量介于给定规则集所指定 OSD 组容量的 30% 到 50% 之间,则您需要重新设置 OSD 的权重。检查各个磁盘,找出其中哪些磁盘的填满速度比其他磁盘更快(或者一般情况下速度更慢),并降低其权重。对于数据写入量不足的 OSD 可以采用相同的思路:可以提高其权重,让 Ceph 将更多的数据写入其中。在下面的示例中,您将确定 ID 为 13 的 OSD 的权重,并将权重从 3 重新设置为 3.05:
$ ceph osd tree | grep osd.13 13 3 osd.13 up 1 $ ceph osd crush reweight osd.13 3.05 reweighted item id 13 name 'osd.13' to 3.05 in crush map $ ceph osd tree | grep osd.13 13 3.05 osd.13 up 1
ceph osd reweight-by-utilization
阈值命令可自动完成降低严重过度使用的 OSD 的权重的过程。默认情况下,此命令将对达到平均使用率的 120% 的 OSD 降低权重,但是,如果您指定了阈值,则命令会改用该百分比。
/var/lib/ceph
的 Btrfs 子卷 #
SUSE Linux Enterprise 默认安装在 Btrfs 分区中。Ceph Monitor 将其状态和数据库存储在 /var/lib/ceph
目录下。为防止 Ceph Monitor 因基于之前某个快照进行的系统回滚而损坏,请为 /var/lib/ceph
创建 Btrfs 子卷。专用子卷会从根子卷的快照中排除 Monitor 数据。
请在运行 DeepSea 阶段 0 之前创建 /var/lib/ceph
子卷,因为阶段 0 会安装与 Ceph 相关的包并创建 /var/lib/ceph
目录。
随后,DeepSea 阶段 3 会验证 @/var/lib/ceph
是否为 Btrfs 子卷,如果它是普通目录,则验证将失败。
需正确安装 Salt 和 DeepSea,并确保它们正常工作。
如果您已安装好集群,则必须符合以下要求:
已将节点升级到 SUSE Enterprise Storage 6,并且集群受 DeepSea 的控制。
Ceph 集群已启动且正常运行。
升级过程已将 Salt 和 DeepSea 扩展模块同步到所有 Minion 节点。
在运行 DeepSea 阶段 0 之前,请对将充当 Ceph Monitor 的每个 Salt Minion 应用以下命令:
root@master #
salt 'MONITOR_NODES' saltutil.sync_allroot@master #
salt 'MONITOR_NODES' state.apply ceph.subvolume
ceph.subvolume
命令会执行以下操作:
创建 /var/lib ceph
,作为 @/var/lib/ceph
Btrfs 子卷。
装入该新子卷并相应地更新 /etc/fstab
。
如果您忘记在运行阶段 0 之前运行第 25.6.2.1 节 “运行 DeepSea 阶段 0 之前”中所述的命令,而 /var/lib/ceph
子目录已存在,则 DeepSea stage 3 验证会失败。要将该子目录转换为子卷,请执行以下操作:
切换到 /var/lib
目录:
cephadm@mon >
cd /var/lib
备份 ceph
子目录的当前内容:
cephadm@mon >
sudo mv ceph ceph-
创建并装入子卷,然后更新 /etc/fstab
:
root@master #
salt 'MONITOR_NODES' state.apply ceph.subvolume
切换到备份子目录,将其内容与新子卷进行同步,然后将其删除:
cephadm@mon >
cd /var/lib/ceph-cephadm@mon >
rsync -av . ../cephcephadm@mon >
cd ..cephadm@mon >
rm -rf ./ceph-
在 SUSE Enterprise Storage 5.5 上,/var
目录不在 Btrfs 子卷上,但其子文件夹(例如 /var/log
或 /var/cache
)是“@”下的 Btrfs 子卷。创建 @/var/lib/ceph
子卷需要先装入“@”子卷(默认未装入),然后在其下创建 @/var/lib/ceph
子卷。
下面的命令示例阐述了该过程:
root #
mkdir -p /mnt/btrfsroot #
mount -o subvol=@ ROOT_DEVICE /mnt/btrfsroot #
btrfs subvolume create /mnt/btrfs/var/lib/cephroot #
umount /mnt/btrfs
此时,@/var/lib/ceph
子卷即创建完毕,您可以按第 25.6.2 节 “部署新集群时所需执行的步骤”中所述继续操作。
在 Ceph Monitor 节点上自动设置 @/var/lib/ceph
Btrfs 子卷可能并不适用于所有场景。您可以执行以下步骤将您的 /var/lib/ceph
目录迁移到 @/var/lib/ceph
子卷:
终止正在运行的 Ceph 进程。
卸载节点上的 OSD。
切换到备份子目录,将其内容与新子卷进行同步,然后将其删除:
cephadm@mon >
cd /var/lib/ceph-cephadm@mon >
rsync -av . ../cephcephadm@mon >
cd ..cephadm@mon >
rm -rf ./ceph-
重新装入 OSD。
重启动 Ceph 守护进程。
有关手动设置的详细信息,请参见 Salt Master 节点上的 /srv/salt/ceph/subvolume/README.md
文件。
对于 OSD 守护进程而言,读/写操作对保持 Ceph 集群平衡至关重要。这些守护进程通常需要同时打开许多文件进行读取和写入。在 OS 级别,同时打开的文件的最大数目称为“文件描述符的最大数目”。
为防止 OSD 用尽文件描述符,您可以覆盖 OS 默认值,并在 /etc/ceph/ceph.conf
中指定该数字,例如:
max_open_files = 131072
更改 max_open_files
之后,需在相关的 Ceph 节点上重启动 OSD 服务。
您可以为 KVM 驱动的虚拟机创建磁盘映像,将该映像存储在 Ceph 存储池中,选择性地将现有映像的内容转换到该映像,然后使用 qemu-kvm
运行虚拟机,以利用集群中存储的磁盘映像。有关详细信息,请参见第 24 章 “Ceph 用作 QEMU KVM 实例的后端”。
libvirt
磁盘 #
类似于 KVM(请参见第 25.8.1 节 “在 Ceph 集群中存储 KVM 磁盘”),您可以使用 Ceph 来存储 libvirt
驱动的虚拟机。这样做的好处是可以运行任何支持 libvirt
的虚拟化解决方案,例如 KVM、Xen 或 LXC。有关详细信息,参见第 23 章 “将 libvirt
与 Ceph 搭配使用”。
使用 Ceph 存储 Xen 磁盘的方法之一是按第 23 章 “将 libvirt
与 Ceph 搭配使用”中所述利用 libvirt
。
另一种方法是让 Xen 直接与 rbd
块设备驱动程序通讯:
如果尚未为 Xen 准备磁盘映像,请新建一个:
cephadm@adm >
rbd create myimage --size 8000 --pool mypool
列出存储池 mypool
中的映像,并检查您的新映像是否在该存储池中:
cephadm@adm >
rbd list mypool
通过将 myimage
映像映射到 rbd
内核扩展模块来创建一个新的块设备:
cephadm@adm >
rbd map --pool mypool myimage
要指定用户名,请使用 --id 用户名
。此外,如果您使用了 cephx
身份验证,则还必须指定机密。该机密可能来自密钥环,或某个包含机密的文件:
cephadm@adm >
rbd map --pool rbd myimage --id admin --keyring /path/to/keyring
或者
cephadm
rbd map --pool rbd myimage --id admin --keyfile /path/to/file
列出所有映射的设备:
rbd showmapped
id pool image snap device
0 mypool myimage - /dev/rbd0
现在,可以将 Xen 配置为使用此设备作为运行虚拟机所用的磁盘。例如,可将下行添加到 xl
样式的域配置文件:
disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]
当防火墙处于工作状态(甚至只是配置了防火墙)时,DeepSea 部署阶段会失败。要正确通过该阶段,需要运行以下命令关闭防火墙
root #
systemctl stop SuSEfirewall2.service
或在 /srv/pillar/ceph/stack/global.yml
中将 FAIL_ON_WARNING
选项设为“False”:
FAIL_ON_WARNING: False
建议使用 SUSE 防火墙保护网络集群通讯。可以通过选择
› › › 来编辑防火墙的配置。下面列出了 Ceph 相关服务以及这些服务通常使用的端口号:
启用
服务或端口 6789 (TCP)。启用
服务或端口 6800-7300 (TCP)。打开端口 3260 (TCP)。
打开对象网关通讯所用的端口。此端口在 /etc/ceph.conf
内以 rgw frontends =
开头的行中设置。HTTP 的默认端口为 80,HTTPS (TCP) 的默认端口为 443。
默认情况下,NFS Ganesha 使用端口 2049(NFS 服务、TCP)和 875 (rquota 支持、TCP)。有关更改默认 NFS Ganesha 端口的详细信息,请参见第 21.2.1.4 节 “更改默认 NFS Ganesha 端口”。
打开用于 HTTP 的端口 80,用于 HTTPS (TCP) 的端口 443。
打开端口 22 (TCP)。
打开端口 123 (UDP)。
打开端口 4505 和 4506 (TCP)。
打开端口 3000 (TCP)。
打开端口 9100 (TCP)。
为方便测试网络性能,DeepSea 的 net
运行程序提供了以下命令:
向所有节点发出简单 ping:
root@master #
salt-run
net.ping Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
向所有节点发出大规模 ping:
root@master #
salt-run
net.jumbo_ping Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
带宽测试:
root@master #
salt-run
net.iperf Fastest 2 hosts: |_ - 192.168.58.106 - 2981 Mbits/sec |_ - 192.168.58.107 - 2967 Mbits/sec Slowest 2 hosts: |_ - 192.168.58.102 - 2857 Mbits/sec |_ - 192.168.58.103 - 2842 Mbits/sec
使用 net.iperf
运行程序运行测试时,所启动的“iperf3”服务器进程不会在测试完成时自动停止。要停止这些进程,请使用以下运行程序:
root@master #
salt '*' multi.kill_iperf_cmd
本节介绍如何使用 libstoragemgmt
和/或第三方工具调整物理磁盘上的 LED 灯。可能并非所有硬件平台都支持此功能。
将 OSD 磁盘与物理磁盘保持匹配是项困难的工作,对磁盘密度较高的节点来说尤为如此。在一些具有 LED 灯的硬件环境中,可使用软件调整 LED 灯,使其以不同的颜色闪烁或发光,从而达到方便识别的目的。SUSE Enterprise Storage 通过 Salt、libstoragemgmt
和特定于所用硬件的第三方工具来提供此功能支持。此功能的配置在 /srv/pillar/ceph/disk_led.sls
Salt pillar 中定义:
root #
cat /srv/pillar/ceph/disk_led.sls
# This is the default configuration for the storage enclosure LED blinking.
# The placeholder {device_file} will be replaced with the device file of
# the disk when the command is executed.
#
# Have a look into the /srv/pillar/ceph/README file to find out how to
# customize this configuration per minion/host.
disk_led:
cmd:
ident:
'on': lsmcli local-disk-ident-led-on --path '{device_file}'
'off': lsmcli local-disk-ident-led-off --path '{device_file}'
fault:
'on': lsmcli local-disk-fault-led-on --path '{device_file}'
'off': lsmcli local-disk-fault-led-off --path '{device_file}'
disk_led.sls
的默认配置通过 libstoragemgmt
层来提供 LED 支持。但 libstoragemgmt
是通过特定于硬件的插件和第三方工具来提供此支持的。因此,除非已安装适用于硬件的 libstoragemgmt
插件和第三方工具,否则 libstoragemgmt
将无法调整 LED。
不论是否安装了 libstoragemgmt
,可能都需要通过第三方工具来调整 LED 灯。众多硬件供应商都提供此类第三方工具。下面是一些常见的供应商和工具:
供应商/磁盘控制器 | 工具 |
---|---|
HPE SmartArray | hpssacli |
LSI MegaRAID | storcli |
SUSE Linux Enterprise Server 还提供了 ledmon 包和 ledctl
工具。此工具可能还适用于使用 Intel 存储机箱的硬件环境。使用此工具的正确语法如下所示:
root #
cat /srv/pillar/ceph/disk_led.sls
disk_led:
cmd:
ident:
'on': ledctl locate='{device_file}'
'off': ledctl locate_off='{device_file}'
fault:
'on': ledctl locate='{device_file}'
'off': ledctl locate_off='{device_file}'
如果您使用的是已安装所有必需第三方工具的受支持硬件,则可以在 Salt Master 节点上使用以下命令语法来启用或禁用 LED:
root #
salt-run disk_led.device NODE DISK fault|ident on|off
例如,要针对 OSD 节点 srv16.ceph
上的 /dev/sdd
启用或禁用 LED 识别或故障灯,请运行以下命令:
root #
salt-run disk_led.device srv16.ceph sdd ident onroot #
salt-run disk_led.device srv16.ceph sdd ident offroot #
salt-run disk_led.device srv16.ceph sdd fault onroot #
salt-run disk_led.device srv16.ceph sdd fault off
在 salt-run
命令中使用的设备名称需要与 Salt 所识别的名称相匹配。您可使用以下命令来显示这些名称:
root@master #
salt 'minion_name' grains.get disks
在许多环境中,为了调整 LED 灯以满足特定的硬件需求,需要对 /srv/pillar/ceph/disk_led.sls
配置进行更改。通过将 lsmcli
替换为其他工具或调整命令行参数,可以进行简单的更改。要实现复杂的更改,则可能需要调用外部脚本,而非使用 lsmcli
命令。对 /srv/pillar/ceph/disk_led.sls
进行任何更改时,均需执行以下步骤:
对 Salt Master 节点上的 /srv/pillar/ceph/disk_led.sls
进行所需更改。
验证 Pillar 数据中是否正确反映了这些更改:
root #
salt 'SALT MASTER*' pillar.get disk_led
使用以下命令刷新所有节点上的 Pillar 数据:
root #
salt '*' saltutil.pillar_refresh
您可以通过外部脚本直接使用第三方工具来调整 LED 灯。下面提供了介绍如何调整 /srv/pillar/ceph/disk_led.sls
以支持外部脚本的示例,以及分别适用于 HP 和 LSI 环境的两个示例脚本。
经过修改的 /srv/pillar/ceph/disk_led.sls
,其中调用了外部脚本:
root #
cat /srv/pillar/ceph/disk_led.sls
disk_led:
cmd:
ident:
'on': /usr/local/bin/flash_led.sh '{device_file}' on
'off': /usr/local/bin/flash_led.sh '{device_file}' off
fault:
'on': /usr/local/bin/flash_led.sh '{device_file}' on
'off': /usr/local/bin/flash_led.sh '{device_file}' off
使用 hpssacli
实用程序在 HP 硬件上闪烁 LED 灯的脚本示例:
root #
cat /usr/local/bin/flash_led_hp.sh
#!/bin/bash
# params:
# $1 device (e.g. /dev/sda)
# $2 on|off
FOUND=0
MAX_CTRLS=10
MAX_DISKS=50
for i in $(seq 0 $MAX_CTRLS); do
# Search for valid controllers
if hpssacli ctrl slot=$i show summary >/dev/null; then
# Search all disks on the current controller
for j in $(seq 0 $MAX_DISKS); do
if hpssacli ctrl slot=$i ld $j show | grep -q $1; then
FOUND=1
echo "Found $1 on ctrl=$i, ld=$j. Turning LED $2."
hpssacli ctrl slot=$i ld $j modify led=$2
break;
fi
done
[[ "$FOUND" = "1" ]] && break
fi
done
使用 storcli
实用程序在 LSI 硬件上闪烁 LED 灯的脚本示例:
root #
cat /usr/local/bin/flash_led_lsi.sh
#!/bin/bash
# params:
# $1 device (e.g. /dev/sda)
# $2 on|off
[[ "$2" = "on" ]] && ACTION="start" || ACTION="stop"
# Determine serial number for the disk
SERIAL=$(lshw -class disk | grep -A2 $1 | grep serial | awk '{print $NF}')
if [ ! -z "$SERIAL" ]; then
# Search for disk serial number across all controllers and enclosures
DEVICE=$(/opt/MegaRAID/storcli/storcli64 /call/eall/sall show all | grep -B6 $SERIAL | grep Drive | awk '{print $2}')
if [ ! -z "$DEVICE" ]; then
echo "Found $1 on device $DEVICE. Turning LED $2."
/opt/MegaRAID/storcli/storcli64 $DEVICE $ACTION locate
else
echo "Device not found!"
exit -1
fi
else
echo "Disk serial number not found!"
exit -1
fi