Ceph:关于Ceph 中管理红帽 Ceph 存储集群(16)

对每个人而言,真正的职责只有一个:找到自我。然后在心中坚守其一生,全心全意,永不停息。所有其它的路都是不完整的,是人的逃避方式,是对大众理想的懦弱回归,是随波逐流,是对内心的恐惧 ——赫尔曼·黑塞《德米安》

写在前面


+

  • 理解不足小伙伴帮忙指正

对每个人而言,真正的职责只有一个:找到自我。然后在心中坚守其一生,全心全意,永不停息。所有其它的路都是不完整的,是人的逃避方式,是对大众理想的懦弱回归,是随波逐流,是对内心的恐惧 ——赫尔曼·黑塞《德米安》


11. 管理红帽 Ceph 存储集群

11.1 执行集群管理和监控

11.1.1 定义Ceph Manager (MGR)

Red Hat Ceph Storage Manager (MGR)的角色是收集集群统计信息

当MGR节点关闭时,客户端I/O操作可以正常地继续,但是对集群统计信息的查询会失败。为每个集群部署至少两个MGRs,以提供高可用性。MGR通常与MON节点运行在相同的主机上,但这不是必需的

在集群中启动的第一个MGR守护进程将成为活动的MGR,而其他所有的MGRs都处于备用状态。如果活动的经理没有在配置的时间间隔内发送信标,则会由一个备用的经理接管。如果需要,可以通过配置mon_mgr _beacon_grace设置来更改信标时间间隔。缺省值是30秒

使用ceph mgr fail 命令手动从主Manager切换到备Manager

使用ceph mgr stat命令查看MGRs的状态

1
2
3
4
5
6
7
[ceph: root@node /]# ceph mgr stat 
{
"epoch": 32,
"available": true,
"active_ name": "mgrl",
"num_standby": 3
}
Ceph MGR 模块

Ceph MGR具有模块化架构。可以根据需要启用或禁用模块,MGR收集集群统计数据,并可将数据传送至外部监察及管理系统

使用ceph mgr module ls命令查看可用的模块和已启用的模块,使用ceph mgr services命令查看特定模块的发布地址,例如Dashboard模块的URL

Ceph仪表板模块

Ceph Dashboard通过基于浏览器的用户界面提供集群管理和监控。Dashboard支持查看集群统计数据和警报,并执行所选的集群管理任务。Ceph Dashboard需要一个激活了Dashboard MGR模块的活动的MGR守护进程

Dashboard依靠Prometheus和Grafana服务来显示收集到的监测数据并生成警报。Prometheus是一款开源的监控和警报工具。Grafana是一个开源的统计绘图工具

仪表板支持基于Ceph指标和配置阈值的警报。Prometheus AlertManager组件负责配置、收集和触发警报。警报在仪表板中显示为通知。可以查看最近告警的详细信息,并将告警静音

11.1.2 监控集群健康

可以使用ceph运行状况命令快速验证集群的状态。该命令返回以下状态之一:

  1. HEALTH_0K 表示集群运行正常

  2. HEALTH_WARN 表示集群处于警告状态。例如,OSD故障,但仍有足够的OSD正常运行

  3. HEALTH_ERR 表示集群处于错误状态。例如,一个完整的OSD可能会对集群的功能产生影响

如果Ceph集群处于警告或错误状态,则Ceph运行状况详细信息命令提供额外的详细信息

1
[ceph: root@node /]# ceph health detail

ceph -w命令显示ceph集群中发生的事件的其他实时监控信息

1
[ceph: root@node /)# ceph -w 

该命令提供了集群活动的状态,例如以下详细信息:

  1. 跨集群的数据均衡

  2. 跨集群的副本恢复

  3. 擦洗活动

  4. osd启停

可以使用ceph -W cephadm命令监控cephadm日志。使用ceph log last cephadm查看最近的日志条目

1
[ceph: root@node /]# ceph -W cephadm

11.1.3 管理Ceph服务

容器化服务由容器主机系统上的systemd控制。在容器主机系统上执行systemctl命令启动、停止或重新启动集群守护进程。

集群守护进程通过$daemon的类型和守护进程$id来引用。$daemon的类型为mon、mgr、mds、osd、rgw、rbd-mirror、crash、cephfs-mirror

MON、MGR和RGW守护进程的$id是主机名。OSD的守护进程$id即为OSD id。MDS的守护进程$id是紧跟主机名的文件系统名

使用ceph orch ps命令列出所有集群守护进程。使用–daemon_ type=DAEM0N选项筛选特定守护进程类型

1
[ceph: root@node /]# ceph orch ps --daemon_type=osd

要停止、启动或重新启动主机上的守护进程,可以使用systemct l命令和守护进程名称

要列出集群主机上所有守护进程的名称,可以运行systemctl list-units命令并搜索ceph

集群fsid位于守护进程名称中。有些服务名称以一个随机的6个字符串结尾,以区分同一主机上相同类型的各个服务

1
[root@node ~]# systemctl list-units 'ceph*'

使用ceph.target管理集群节点上所有守护进程

1
[root@node ~]# systemctl restart ceph.target

也可以使用ceph orch命令来管理集群服务。首先,使用ceph orch ls命令获取服务名称。例如,查找集群OSDs的服务名称,重新启动服务

1
[ceph: root@node /]# ceph orch ls
1
[ceph: root@node /)# ceph orch restart osd.default_drive_group

可以使用ceph orch daemon命令管理单个集群守护进程

1
[ceph: root@node /]# ceph orch daemon restart osd.1

11.1.4 电源关闭或重新启动集群

Ceph支持集群标志来控制集群的行为。重启集群或执行集群维护时,必须设置一些标志。可以使用群集标志来限制失败的群集组件的影响或防止群集性能问题。

使用ceph osd setceph osd unset命令管理这些标志:

  • noup
    不要自动将一个正在启动的OSD标记为up。
    如果集群网络遇到延迟问题,osd可以在MON上标记对方为down,然后标记自己为up。这种情况被称为flapping。
    设置noup和nodown的flag,以防止振荡(flapping)

  • nodown
    nod自己的标志告诉Ceph MON用down状态标记一个停止的OSD。
    在进行维护或关闭集群时使用nodown标志。
    设置nodown标志以防止振荡(flapping)

  • noout
    noout标志告诉Ceph MON不要从CRUSH map中移除任何osd,这将阻止CRUSH在osd停止时自动重新平衡集群。
    在对集群的子集进行维护时使用noout标志。
    重启osd后清除标志

  • noin
    noin标志可以防止osd在引导时被标记为in状态。
    该标志防止数据被自动分配给特定的OSD

  • norecover
    norecover标志阻止恢复操作运行。
    在进行维护或关闭集群时使用norecover标志

  • nobackfill
    nobackfil标志阻止回填操作运行。在进行维护或集群关闭时使用nobackfil标志

  • norebalance
    norebalance标志阻止重新平衡操作运行。在进行维护或关闭集群时使用norebalance标志

  • noscrub
    noscrub标志阻止清除操作运行

  • nodeep-scrub
    nodeep-scrub标志阻止任何深层清洗操作的运行

集群断电

请执行以下步骤关闭整个集群。

  1. 禁止客户端访问集群

  2. 在继续之前,确保集群处于健康状态(HEALTH_ OK),并且所有pg处于active+clean状态

  3. 关闭CephFS

  4. 设置noout、norecover、norebalance、nobackfill、nodown和pause标志

  5. 关闭所有Ceph对象网关(RGW)和iSCSI网关

  6. 逐一关闭OSD

  7. 逐个关闭MON节点和MGR节点

  8. 关闭管理节点

集群加电

集群上电操作步骤如下:

  1. 集群节点上电顺序:admin节点、MON节点和MGR节点、OSD节点、MDS节点

  2. 清除noout,norecover,norebalance, nobackfill,nodown 和pause 标志

  3. 打开Ceph对象网关和iSCSI网关

  4. 开启CephFS

11.1.5 监控集群

使用ceph mon statceph quorum_status -f json-pretty命令查看MON仲裁状态

1
[ceph: root@node /]# ceph mon stat 
1
[ceph: root@node /]# ceph quorum_status -f json-pretty

也可以在“Dashboard”中查看MONs的状态

查看日志守护进程

可以使用journalctl -u $daemon@$id命令查看守护进程日志。
要只显示最近的日志条目,请使用-f选项。
例如,这个示例查看该主机的OSD 10守护进程的日志

1
2
[root@node -]$ journalctl \
-u ceph-ff97a876-1fd2-11ec-8258-52540000fa0c@osd.10.service

Ceph容器为每个守护进程写入单独的日志文件。
通过配置守护进程的log_to_file设置为rue,为每个特定的Ceph守护进程启用日志记录。
这个示例启用了MON节点的日志记录功能

1
[ceph: root@node /]# ceph config set mon log_to_file true

11.1.6 监控osd

如果集群不健康,Ceph将显示详细的状态报告,其中包含以下信息:

  1. osd当前状态(up/down/out/in)

  2. OSD近容量限制信息(nearfull/full)

  3. 放置组(pg)的当前状态

ceph状态和ceph健康命令报告与空间相关的警告或错误条件。各种ceph osd子命令可以报告osd使用的详细信息、状态和位置信息

分析OSD使用

ceph osd df命令用来查看osd使用统计信息。可使用ceph osd df tree命令查看CRUSH树

1
[ceph: root@node /]# ceph osd df 

输出信息说明如下表所示:

输出列 描述
ID OSD ID
CLASS OSD使用的设备类型(HDD、SDD或NVMe)
WEIGHT 在crush地图中OSD的权重。
默认设置为OSD容量,单位为TB,通过ceph OSD crush reweight命令修改。
权重决定了相对于其他OSD,有多少数据被CRUSH到OSD上。
例如,两个具有相同权重的osd接收大致相同数量的I/O请求,存储大致相同数量的数据
REWEIGHT reweight的默认值或ceph osd reweight命令设置的实际值。
可以对OSD重新加权,以临时覆盖CRUSH权重
SIZE OSD的总存储容量
RAW USE OSD的已用存储容量
DATA 用户数据占用的OSD容量
OMAP BlueFS存储用于存储OMAP (object map)数据,这些数据是存储在RocksDB中的键值对
META 分配的总BlueFS空间,或bluestore_bluefs_min设置的值,以较大的值为准。
这是内部的BlueStore元数据,它计算为分配给BlueFS的总空间减去估计的OMAP数据大小
AVAIL OSD上的空闲空间
%USE OSD使用的存储容量百分比
VAR 高于或低于平均OSD利用率的变化
PGS OSD上放置组的个数
STATUS OSD的状态

使用ceph osd perf命令查看osd性能统计信息

1
[ceph: root@node /]# ceph osd perf
解释OSD状态

基于这两个标志的组合,OSD守护进程可以处于以下四种状态之一:

  • down或up
    表示守护进程是否正在运行并与MONs通信

  • out或in
    表示OSD是否参与集群数据放置

正常运行的OSD状态为up and in

如果一个OSD失败,守护进程脱机,集群可能会在短时间内将其报告为停机和正常运行。
这是为了让OSD有机会自己恢复并重新加入集群,避免不必要的恢复流量

例如,短暂的网络中断可能会导致OSD与集群失去通信,并被临时上报为down。
通过mon_ osd_down_out_interval配置选项控制的短时间间隔(默认为5分钟),集群会报告osd down 和 out。
此时,分配给失败OSD的放置组被迁移到其他OSD

如果失败的OSD恢复up状态,则集群根据新的OSD集合重新分配位置组,并重新平衡集群中的对象

使用ceph osd set nooutceph osd unset noout命令,在集群上启用或禁用noout标志。
但是,ceph osd out osd id命令会告诉ceph集群忽略某个osd进行数据放置,并将该osd标记为out状态

osd定期(默认为6秒)验证彼此的状态。
默认情况下,它们每120秒向MONs报告一次状态。
如果一个OSD down,其他OSD或mon将无法接收到该down OSD的心跳响应

管理OSD心跳的配置设置如下:

配置选项 描述
osd_heartbeat_interval OSD peer 检查间隔的秒数
osd_heartbeat_grace 无响应OSD变为down状态的时间间隔
mon_osd_min_down_reporters 在MON认为OSD down掉之前上报OSD down掉的peer数
mon_osd_min_down_reports 一个MON认为OSD是down的次数
mon_osd_down_out_subtree_limit 防止CRUSH单元类型(如主机)在失败时被自动标记为out
osd_mon_report_interval_min 一个新启动的OSD必须在这个秒数内向MON报告
osd_mon_report_interval_max 从OSD到MON上报的最大秒数
osd_mon_heartbeat _interval Ceph监测心跳间隔
mon_osd_report_timeout 如果OSD没有上报,则MON之前的超时时间(以秒为单位)将其标记为down
监控OSD容量

Red Hat Ceph Storage 提供配置参数,防止由于集群内存储空间不足导致数据丢失。通过设置这些参数,可以在osd存储空间不足时发出告警。

当达到或超过mon_osd_full_ratio设置值时,集群停止接受来自客户端的写请求,并进入HEALTH_ERR状态。
系统默认的满配率为集群可用存储空间的0.95(95%)。
使用全比例来保留足够的空间,以便在osd失败时,仍然有足够的空间使自动恢复成功,而不会耗尽空间。

mon_ osd_nearfull_ratio设置是更保守的限制。
当mon_ osd_nearfull_ratio限制达到或超过该值时,集群进入HEALTH WARN状态。
这是为了提醒需要向集群中添加osd或在达到完全比例之前修复问题。
默认接近满比率为集群可用存储空间的0.85(85%)

mon_osd_backfill_fulll_ratio设置是认为集群osd已满而无法开始回填操作的阈值。系统默认回填满率为集群可用存储空间的90%,即0.90。

使用命令ceph osd set- full-ratioceph osd set-nearfull-ratioceph osd set- backfilfull-ratio进行设置

1
2
3
[ceph: root@node /]# ceph osd set-full-ratio .85 
[ceph: root@node /]# ceph osd set-nearfull-ratio .75
[ceph: root@node /]# ceph osd set-backfillfull-ratio .80

默认的比率设置适用于小型集群,例如本实验室环境中使用的集群。
生产集群通常需要较低的比例

不同的osd可能是满的,也可能是少的,具体取决于哪些对象存储在哪个放置组中。如果你的一些osd已经满了或者满了,而其他的osd还有很多空间,那么你需要分析你的放置组分布和CRUSH map权重

11.1.7 监控放置组

每个放置组(PG)都有一个分配给它的状态字符串,指示其运行状况状态

当所有放置组都处于==active+clean==状态时,集群是健康的。
scrubbing或deep-scrubbing的PG状态也可能发生在健康的群集中,但并不表示有问题

放置组清除是一个后台进程,它通过将对象的大小和其他元数据与其他osd上的副本进行比较并报告不一致的地方来验证数据的一致性

deep-scrubbing是一个资源密集型的过程,它通过使用按位比较来比较数据对象的内容,并重新计算校验和来识别驱动器上的坏扇区

尽管清除操作对于维护健康的集群至关重要,但它们也会对性能产生影响,尤其是深度清除。安排擦洗以避免I/O高峰时间。
暂时用noscrub和nodeep-scub的flag防止擦洗操作

放置组可以有以下状态:

PG 状态 描述
creating 正在进行PG创建
peering osd正在就PG中对象的当前状态达成一致
==active== 完成对等连接。PG可用于读写请求
==clean== PG有正确的副本数量,没有流浪副本
degraded PG具有副本数量不正确的对象
recovering 对象正在通过副本进行迁移或同步
recovery_wait PG正在等待当地或远程的预订
undersized PG被配置为存储比放置组可用的osd更多的副本
inconsistent 这个PG的副本不一致。PG中的一个或多个副本是不同的,表明PG有某种形式的破坏
replay 在OSD崩溃后,PG正在等待客户端重放日志中的操作
repair PG计划进行维修
backfill、backfill_wait、backfill_toofull 回填操作正在等待、发生或由于存储空间不足而无法完成
incomplete PG从历史日志中丢失了可能发生的写入的信息。这可能表明一个OSD已经失败或未启动
stale 日志含义PG状态未知(OSD报告超时)
inactive PG已经不活跃太久了
unclean PG已经不干净太久了
remapped 当主OSD恢复或回填时,作用集发生了变化,PG临时重新映射到另一组OSD
down PG离线
splitting PG正在被拆分; pg的数量正在增加
scrubbing, deep-scrubbing 正在进行PG擦洗或深度擦洗操作

当一个OSD加入放置组后,PG会进入peer状态,以保证所有节点对该OSD的状态达成一致,如果对等体状态完成后,PG还能处理读写请求,则上报活动状态。如果PG对于它的所有对象也有正确的副本数量,那么它报告一个干净的状态。写操作完成后,正常的PG操作状态是active+clean。

当一个对象被写入PG的主OSD时,PG会报告降级状态,直到所有的副本OSD都承认已经写入该对象

回填状态表示数据正在进行复制或迁移,以实现各osd间pg组的再平衡。当在PG中增加一个新的OSD时,为避免网络流量过大,会逐步对该OSD进行对象回填。回填操作采用后台操作,最大限度减少对集群性能的影响

backfill_wait状态表示回填等待中。回填状态表示回填操作正在进行。backfill_too_ful l状态:请求回填,但由于存储空间不足无法完成

标记为不一致的PG可能具有不同于其他副本的副本,在一个或多个副本上检测到不同的数据校验和或元数据大小。Ceph集群中的时钟偏差和损坏的对象内容也会导致PG状态不一致

识别被卡住的安置组

放置组在失败后转换为降级或对等状态。如果放置组长时间处于这些状态之一,则MON将放置组标记为卡住。被卡住的PG可能会处于以下一种或多种状态:

  1. inactive 的PG可能会有peer问题

  2. unclean 的PG 可能有问题后恢复失败

  3. stale PG没有osd报告,这可能表明所有的osd都失败了

  4. undersized 的PG没有足够的osd来存储配置的副本数量

MONs使用mon_pg_stuck_threshold参数来决定PG是否已经处于错误状态太久。
该阈值的缺省值是300秒

当拥有特定PG副本的所有osd处于down和out状态时,Ceph将PG标记为stale。
要从失效状态返回,OSD必须被恢复以获得PG副本并开始PG恢复。
如果情况仍然没有解决,PG是不可访问的,如果I/O请求PG挂起

默认情况下,Ceph执行自动恢复。
如果任何pg恢复失败,集群状态继续显示HEALTH_ERR

Ceph可以声明一个osd或PG丢失,这可能会导致数据丢失。
要确定受影响的osd,首先使用ceph运行状况详细信息命令检索集群状态概览。
然后使用ceph pg dump_stuck OPTION命令检查pg的状态

如果有很多pg一直处于对等状态,使用ceph osd blocked-by命令查看正在阻止该osd peer的osd

检查PG使用ceph pg dump | grep pgid或ceph pg query pgid命令。
托管PG的osd显示在方括号([])中。

要将PG标记为丢失,请使用ceph pg pgid mark_unfound_lost revert | delete命令。要将一个OSD标记为丢失,使用ceph osd lost OSD.ID –yes-i-really-mean-it命令。OSD的状态必须为down out

11.1.8 集群升级

使用ceph orch upgrade命令升级您的Red Hat ceph Storage 5集群。

首先,通过运行cephadm-ansible preflight剧本,并将upgrade_cepph_packages选项设置为true来更新cephadm

使用ceph orch upgrade命令升级Red Hat ceph Storage 5集群

首先,更新cephadm通过运行cephadm-ansible preflight playbook与upgrade_cepph_packages选项设置为true

1
2
3
[root@node ~]# ansible-playbook \
-i /etc/ansible/hosts/cephadm-preflight.yml \
--extra-vars "ceph_origin=rhcs upgrade_ceph_packages=true"

然后执行ceph orch upgrade start –ceph-version VERSION命令

1
2
[ceph: root@node /]# ceph orch upgrade start \
--ceph-version 16.2.0-117.el8cp

执行ceph status命令,查询升级进度

1
2
3
4
[ceph: root@node /)# ceph status 
... output omitted ...
progress:
Upgrade to 16.2.0-115 .el8cp (ls)

不要将使用不同版本的Red Hat Ceph Storage的客户端和集群节点混合在同一个集群中。
客户端包括RADOS网关、iSCSI网关以及其他使用librados、librbd或libceph的应用程序。

在集群升级后,使用ceph versions命令检查是否安装了匹配的版本

1
[ceph: root@node /]# ceph versions 

11.1.9 使用Balancer模块

Red Hat Ceph Storage提供了一个名为balancer的MGR模块,它可以自动优化PGs在osd之间的放置,以实现均衡分布。该模块也可以手动运行

如果集群的状态不是HEALTH_OK,则不运行balancer模块。
当集群处于健康状态时,它将限制其更改,以便将需要移动的pg数量保持在5%的阈值以下。
配置target_max_misplaced_ratio MGR设置来调整这个阈值:

1
2
[ceph: root@node /]# ceph \
config set mgr.* target_max_misplaced_ratio .10

缺省情况下,balancer模块处于启用状态。使用ceph balancer on和ceph balancer off命令启用或禁用平衡器。

ceph balancer status命令用来查看均衡器状态。

1
[ceph: root@node /]# ceph balancer status 
自动平衡

自动平衡使用以下模式之一:

  • crush-compat
    该模式使用compat权集特性来计算和管理CRUSH层次结构中设备的另一组权值。
    平衡器优化这些权重设置值,以较小的增量向上或向下调整它们,以实现与目标分布尽可能接近的分布。
    此模式完全向后兼容旧客户端

  • upmap
    PG upmap模式允许在OSD映射中存储单个OSD的显式PG映射,而正常的CRUSH放置ca除外。
    upmap模式分析PG布局,然后运行所需的pg-upmap-iterns命令来优化PG布局,实现均衡分布

因为这些upmap条目提供了对PG映射的细粒度控制,upmap模式通常能够在osd中平均分配PG,或者如果PG数量是奇数,则可以使用+/-1 PG。

将模式设置为upmap要求所有客户端都是luminous 或更新的。
使用ceph osd set-require-min-compat-client luminous命令设置所需的最小客户端版本

使用ceph balancer mode upmap命令设置均衡模式为upmap

1
[ceph: root@node /]# ceph balancer mode upmap

使用ceph balancer mode crush- compat命令将均衡器模式设置为crush-compat

1
[ceph: root@node /]# ceph balancer mode crush-compat
手动平衡

可以手动运行平衡器来控制均衡发生的时间,并在执行之前对平衡器计划进行评估。如果需要手动运行平衡器,可以使用以下命令禁用自动均衡,然后生成并执行一个计划。

  1. 评估并为集群的当前分布打分

    1
    [ceph: root@node /]# ceph balancer eval
  2. 对特定池的当前分布进行评估和评分

    1
    [ceph: root@node /]# ceph balancer eval POOL_NAME 
  3. 生成PG优化计划并为其命名

    1
    [ceph: root@node /]# ceph balancer optimize PLAN_NAME
  4. 显示计划的内容

    1
    [ceph: root@node /]# ceph balancer show PLAN_NAME
  5. 分析计划执行的预期结果

    1
    [ceph: root@node /]# ceph balancer eval PLAN_NAME
  6. 如果您认可预期的结果,那么就执行计划

    1
    [ceph: root@node /]# ceph balancer execute PLAN_NAME

只有在你希望它改善分布时才执行计划。计划执行后被丢弃

使用ceph balancer ls命令显示当前记录的计划

1
[ceph: root@node /]# ceph balancer ls

使用ceph balancer rm命令删除计划

1
[ceph: root@node /]# ceph balancer rm PLAN NAME

11.2 集群维护操作

11.2.1 添加/移除OSD节点

在集群维护活动期间,集群可以在降级状态下操作和服务客户端。
但增加或移除osd会影响集群性能。
回填操作会导致osd之间的数据传输量过大,导致集群性能下降

在执行集群维护活动之前,评估潜在的性能影响。在添加或移除OSD时,影响集群性能的主要因素如下:

  • 客户端负载
    如果某个OSD所在的池中客户端负载过高,则会对性能和恢复时间造成影响。
    由于写操作需要通过数据复制来实现弹性,写密集型客户端负载会增加集群恢复时间

  • 节点的能力
    节点扩容或移除会影响集群恢复时间。
    节点的存储密度也会影响恢复时间。
    例如,36个osd节点的恢复时间比12个osd节点的恢复时间长

  • 集群备用容量
    在移除节点时,请确认有足够的空闲容量,以避免达到完全或接近完全的比例。
    当集群达到全比例时,Ceph会暂停写操作,防止数据丢失

  • CRUSH的规则
    一个Ceph OSD节点映射到至少一个CRUSH等级,并且这个等级通过CRUSH规则映射到至少一个池。
    在添加和删除osd时,每个使用特定CRUSH层次结构的池都会受到性能影响

  • 池类型
    复制池使用更多的网络带宽来复制数据副本,而erasure-coded池使用更多的CPU来计算数据和编码块。
    存在的数据副本越多,集群恢复所需的时间就越长。
    例如,具有许多块的擦除编码池比具有较少相同数据副本的复制池需要更长的恢复时间

  • 节点的硬件
    具有较高吞吐量特性的节点(如10gbps网络接口和ssd)比具有较低吞吐量特性的节点(如1gbps网络接口和SATA驱动器)恢复速度更快

11.2.2 更换故障的OSD

红帽Ceph存储被设计为自愈。
当存储设备出现故障时,其他osd上多余的数据副本会自动回填,使集群恢复健康状态

当存储设备故障时,OSD状态变为down。
其他集群问题,比如网络错误,也会将OSD标记为关闭。
当OSD关闭时,首先检查物理设备是否故障

更换故障的OSD需要同时更换物理存储设备和软件defined OSD。
当某个OSD故障时,可以替换该物理存储设备,也可以重用该OSD ID或创建新的OSD ID。
重用同一个OSD ID可以避免重新配置CRUSH Map,如果有OSD故障,可以通过Dashboard界面或CLI命令替换该OSD

执行以下步骤检查OSD是否故障

  1. 查看集群状态,确认是否有OSD故障

    1
    [ceph: root@node /]# ceph health detail 
  2. 识别故障OSD

    1
    [ceph: root@node /]# ceph osd tree | grep -i down 
  3. 定位OSD所在的OSD节点

    1
    [ceph: root@node /]# ceph osd find osd.OSD_ID
  4. 尝试启动失败的OSD

    1
    [ceph: root@node /]# ceph orch daemon start OSD_ID

如果OSD没有启动,则可能是物理存储设备故障。
使用journalctl命令查看OSD日志,或者使用生产环境中可用的实用程序来验证物理设备是否故障。
如果确认需要更换物理设备,请执行以下步骤。

  1. 暂时禁用擦洗

    1
    2
    3
    [ceph: root@node /]# 
    ceph osd set noscrub;
    ceph osd set nodeep-scrub
  2. 将OSD从集群中移除

    1
    [ceph: root@node /]# ceph osd out OSD_ID 
  3. 观察群集事件并验证已启动回填操作

    1
    [ceph: root@node /]# ceph -w 
  4. 确认回填进程已经将所有pg从OSD上移走,现在可以安全移除了

    1
    [ceph: root@node /]# while ! ceph osd safe-to-destroy osd.OSD_ID; do sleep 1s; done
  5. 当OSD可以安全移除时,更换物理存储设备并销毁OSD。可以选择从设备中删除所有数据、文件系统和分区

    1
    [ceph: root@node /]# ceph orch device zap HOST_NAME OSD_ID --force

通过Dashboard界面或ceph-volume lvm list或ceph osd metadata CLI命令查找当前设备ID

  1. 更换故障OSD,使用与故障OSD相同ID的OSD。在继续之前,请确认操作已完成

    1
    2
    [ceph: root@node /]# ceph orch osd rm OSD_ID --replace 
    [ceph: root@node /]# ceph orch osd rm status
  2. 更换物理设备,重建OSD。新的OSD与故障的OSD使用相同的OSD ID,新存储设备的设备路径可能与故障设备不一致,使用ceph orch device ls命令查找新的设备路径

    1
    [ceph: root@node /]# ceph orch daemon add osd HOST_NAME:DEVICE PATH
  3. 启动OSD,确认OSD状态正常

    1
    2
    [ceph: root@node /]# ceph orch daemon start OSD_ID 
    [ceph: root@node /]# ceph osd tree
  4. 重新启用擦洗

    1
    2
    [ceph: root@node /]# ceph osd unset noscrub
    [ceph: root@node /]# ceph osd unset nodeep-scrub

11.2.3 添加MON

通过执行以下步骤将MON添加到集群:

  1. 验证当前MON计数和放置

    1
    [ceph: root@node /]# ceph orch ls --service_type=mon 
  2. 向集群中添加新主机

    1
    2
    3
    [ceph: root@node /)# ceph cephadm get-pub-key > ~/ceph.pub 
    [ceph: root@node /)# ssh-copy-id -f -i ~/ceph.pub root@HOST_NAME
    [ceph: root@node /)# ceph orch host add HOST_NAME
  3. 指定MON节点应该运行的主机

    1
    [ceph: root@node /)# ceph orch apply mon --placement="NODEl NODE2 NODE3 NODE4"

使用该命令时需要指定所有MON节点。如果只指定新的MON节点,那么该命令将删除所有其他的MON,使集群只剩下一个MON节点

11.2.4 删除一个MON

使用ceph orch apply mon命令从集群中删除一个mon。指定除要删除的mon外的所有mon

1
[ceph: root@node /]# ceph orch apply mon --placement="NODEl NODE2 NODE3"

11.2.5 设置主机进入维护模式

使用ceph orch host maintenance命令设置主机进入或退出维护模式。
维护模式停止主机上所有Ceph守护进程。使用可选的–force选项可以绕过警告

1
[ceph: root@node /]# ceph orch host maintenance enter HOST_NAME [--force] 

维护结束后,退出维护模式

1
[ceph: root@node /]# ceph orch host maintenance exit HOST_NAME

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有,如有侵权请告知,这是一个开源项目,如果你认可它,不要吝啬星星哦 :)



© 2018-至今 liruilonger@gmail.com, All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)

发布于

2023-06-14

更新于

2025-02-04

许可协议

评论
加载中,最新评论有1分钟缓存...
Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×