ceph心跳丢失问题分析

合集下载

ceph_health_status 指标 -回复

ceph_health_status 指标-回复Ceph是一个分布式存储系统，被广泛用于构建高可靠性、高性能的存储解决方案。

Ceph提供了大规模数据存储和访问的能力，并能适应各种应用和工作负载。

在Ceph中，ceph_health_status指标被用于表示Ceph 集群的健康状态。

本文将深入探讨ceph_health_status指标，并逐步回答一些与该指标相关的问题。

第一步：理解ceph_health_status指标及其意义Ceph健康状态（ceph_health_status）是一个用于描述Ceph集群整体健康状况的指标。

它通过检查集群的各个组件和子系统，并分析其状态来确定集群的健康性。

健康状态的不同取值代表了集群不同的健康程度，通常包括健康（HEALTH_OK）、警告（HEALTH_WARN）和错误（HEALTH_ERR）三种状态。

对于一个复杂的分布式系统来说，监控其健康状态非常重要。

健康状态能够提供集群的整体运行状态，允许管理员及时发现并解决问题，确保系统的正常运行。

第二步：指标的获取和展示在Ceph中，可以使用命令行工具（如ceph status）或通过RESTful API 来获取ceph_health_status指标的值。

这些工具将显示集群的整体健康状态并提供详细的健康报告。

管理员可以根据这些信息来诊断和解决问题。

第三步：指标的含义和可能的取值ceph_health_status指标的取值可以是HEALTH_OK、HEALTH_WARN 或HEALTH_ERR。

每个取值代表了集群不同的健康程度和可能的问题：1. HEALTH_OK：表示集群正常运行，各个组件和子系统都处于健康状态。

这是理想的状态，表明集群没有明显的问题。

2. HEALTH_WARN：表示集群存在潜在的问题，但集群依然可以正常运行。

这些问题可能包括未达到预期的数据复制级别、故障磁盘或网络问题。

虽然集群仍然可用，但管理员应该尽快解决这些问题，以避免进一步的故障。

IP改变引起的Cephmonitor异常及OSD盘崩溃的总结

IP改变引起的Cephmonitor异常及OSD盘崩溃的总结IP改变引起的Ceph monitor异常及OSD盘崩溃的总结公司搬家，所有服务器的ip改变。

对ceph服务器配置好ip后启动，发现monitor进程启动失败，monitor进程总是试图绑定到以前的ip地址，那当然不可能成功了。

开始以为服务器的ip设置有问题，在改变hostname、ceph.conf等方法无果后，逐步分析发现，是monmap 中的ip地址还是以前的ip，ceph通过读取monmap来启动monitor 进程，所以需要修改monmap。

方法如下：1.#Add the new monitor locations2.# monmaptool --create --add mon0 192.168.32.2:6789--add osd1 192.168.32.3:6789 \3. --add osd2 192.168.32.4:6789 --fsid 61a520db-317b-41f1-9752-30cedc5ffb9a \4. --clobber monmap5.6.#Retrieve the monitor map7.# ceph mon getmap -o monmap.bin8.9.#Check new contents10.# monmaptool --print monmap.bin11.12.#Inject the monmap13.# ceph-mon -i mon0 --inject-monmap monmap.bin14.# ceph-mon -i osd1 --inject-monmap monmap.bin15.# ceph-mon -i osd2 --inject-monmap monmap.bin再启动monitor，一切正常。

但出现了上一篇文章中描述的一块osd盘挂掉的情况。

查了一圈，只搜到ceph的官网上说是ceph的一个bug。

ceph 原理

ceph 原理Ceph原理Ceph是一种开源的分布式存储系统，它被设计用于提供高性能、高可靠性和可扩展性的存储解决方案。

Ceph的原理基于RADOS（可靠自主分布式对象存储）技术，采用了分布式存储和对象存储的理念，旨在解决传统存储系统中的各种挑战和瓶颈。

一、分布式存储Ceph的核心思想是将数据分布到多个存储节点上，通过数据的分散存储和冗余备份来提高可靠性和性能。

每个节点都可以同时扮演存储节点和计算节点的角色，形成一个分布式存储集群。

数据被划分为多个对象，并通过唯一的对象ID进行标识和索引。

Ceph采用了动态数据分布机制，通过CRUSH算法（Controlled Replication Under Scalable Hashing）将对象映射到存储节点上。

CRUSH算法基于一致性哈希函数，能够将对象均匀分布到存储节点上，避免了传统存储系统中的数据热点问题。

同时，CRUSH算法还考虑了存储节点的负载情况和网络拓扑结构，能够根据实际情况进行动态的数据迁移和负载均衡，提高系统的性能和可扩展性。

二、对象存储Ceph将数据以对象的形式进行存储和管理，每个对象都有一个唯一的标识符和元数据。

对象的大小可以根据需求进行灵活设置，Ceph 能够支持从几KB到几TB不等的对象大小。

Ceph通过RADOS Gateway提供了对象存储接口，支持通过RESTful API和S3/Swift协议来访问和管理对象。

用户可以通过标准的HTTP 请求来上传、下载和删除对象，实现了与传统的文件系统和块存储的兼容性。

三、数据冗余和容错性Ceph在数据分布和存储过程中采用了冗余备份机制，确保数据的可靠性和容错性。

每个对象都会被复制到多个存储节点上，形成数据的冗余备份。

Ceph支持灵活的副本策略，用户可以根据需求设置副本的数量和位置。

Ceph通过心跳机制和故障检测算法来监测存储节点的状态，一旦发现节点故障或数据错误，系统会自动进行数据恢复和修复。

ceph运维手册

ceph运维手册一、介绍Ceph是一个分布式存储系统，具有高性能、高可靠性和高可扩展性的特点。

在大规模数据存储领域，Ceph已经成为一种非常流行的解决方案。

本文将深入探讨Ceph的运维手册，包括必要的配置、监控、故障处理等方面。

二、环境准备在进行Ceph的运维工作之前，需要准备以下环境：1.硬件设备：Ceph要求至少3台服务器，并且每台服务器要有足够的计算和存储资源。

2.操作系统：推荐使用Linux操作系统，例如CentOS、Ubuntu等。

3.网络配置：确保服务器之间能够正常通信，并且网络带宽要足够支持存储系统的数据传输。

三、Ceph集群部署3.1 安装Ceph软件包在每台服务器上执行以下命令，安装Ceph软件包：$ sudo apt-get install ceph -y3.2 配置Ceph集群1.创建一个用于存储Ceph配置文件的目录：$ sudo mkdir /etc/ceph2.在主节点上执行以下命令，生成配置文件：$ sudo ceph-deploy new <主节点>3.编辑生成的Ceph配置文件，添加以下内容：osd pool default size = 2osd crush chooseleaf type = 14.在主节点上执行以下命令，部署配置文件到所有节点：$ sudo ceph-deploy --overwrite-conf config push <所有节点>3.3 启动Ceph集群在主节点上执行以下命令，启动Ceph集群：$ sudo ceph-deploy mon create-initial四、Ceph监控Ceph提供了一套监控工具，可以用于实时监控集群的状态和性能。

4.1 安装和配置监控工具在主节点上执行以下命令，安装和配置监控工具：$ sudo apt-get install ceph-mgr ceph-mgr-dashboard -y4.2 访问监控面板通过浏览器访问主节点的IP地址和监控面板端口，例如：主节点IP地址>:7000。

Ceph常见问题百科全书

Ceph常见问题百科全书Ceph是目前炙手可热的一个统一分布式存储系统，具有优异的性能、可靠性、可扩展性。

其可轻松扩展到数PB 容量，支持多种工作负载的高性能（每秒输入/输出操作[IOPS]和带宽），具有极其高的可靠性。

Ceph对比HDFS优势在于易扩展，无单点。

HDFS是专门为Hadoop这样的云计算而生，在离线批量处理大数据上有先天的优势，而Ceph是一个通用的实时存储系统，具有相当好的超大数量小文件处理能力，且现在Hadoop可以利用Ceph作为存储后端。

Ceph最近加入到Linux 中令人印象深刻的文件系统备选行列，能够在维护POSIX 兼容性的同时加入了复制和容错功能，成为现在分布式系统的掌上明珠。

而在Ceph系统的搭建过程中会出现种种意想不到问题，真的是稀奇古怪的让人意想不到的问题，整个过程中看似每一步都正确，感觉都对，结果还是出现各种问题，更可恨的是其中遇到的很多问题在网上并不能搜索到，有的从国外论坛上能搜索到但是并没有答案（正如硬件开发时候经常出现都对都不对，重启一下全都对的情况）。

然而对于Ceph这块重启并不能解决问题，还需一步一步踏踏实实的进行研究，分析解决问题，并进行总结。

笔者在此对Ceph开发过程中的血泪经验在此与大家分享，对本人在Ceph研发过程中遇到的错误进行记录并提出解决方案，一来是做个总结，二来是为此后进行Ceph开发的大家指出雷区，使大家少爬一点坑，希望能做出一点微小的贡献。

从基础环境开始在Ceph环境搭建过程中的常见问题有（在此按照问题出现的频率进行粗略排序）采用系统为Centos7（谨以此作为示例）1. 执行命令：#ceph-deploy install admin-node node1 node2 node3ERROR：[ceph_deploy][ERROR ]RuntimeError: Failed toexecute command: yum -y install epel-release解决办法：进入/etc/yum.repos.d中删除epel.repo和epel-testing.repo2. 执行命令：#ceph-deploy install admin-node node1 node2 node3ERROR：[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: rpm -Uvh --replacepkgs解决办法：进入/etc/yum.repos.d/ceph.repo文件将所有的源改为网易163源，或者阿里源（经测试网易163源更好用点）编辑ceph 源的配置文件，vim /etc/yum.repo.d/ceph.repo，更改为如下内容：[Ceph]name=Ceph packages for $basearchbaseurl=http:// /ceph /rpm-jewel/el7/$basearchenabled=1gpgcheck=1type=rpm-mdgpgkey=https:// /ceph /keys/release.ascpriority=1[Ceph-noarch]name=Ceph noarch packagesbaseurl=http:// /ceph /rpm-jewel/el7/noarchenabled=1gpgcheck=1type=rpm-mdgpgkey=https:// /ceph /keys/release.ascpriority=1[ceph-source]name=Ceph source packagesbaseurl=http:// /ceph /rpm-jewel/el7/SRPMSenabled=1gpgcheck=1type=rpm-mdgpgkey=https:// /ceph /keys/release.ascpriority=1编辑完成之后保存退出并运行yum clean all && yum makecacheCeph官网提供的在一些情况下非常不好用。

ceph swift原理 -回复

ceph swift原理-回复Ceph Swift原理是一种针对分布式文件存储系统的解决方案。

它结合了Ceph分布式存储系统和OpenStack Swift对象存储系统的优点，提供高可靠性、高扩展性和高性能的存储服务。

一、Ceph简介Ceph是一种旨在提供可靠的、多租户的对象和块存储以及文件系统服务的开源分布式存储系统。

它以容忍故障的设计方式构建，具有自动数据复制和恢复的能力。

Ceph存储系统由多个存储集群组成，每个集群由多个存储节点组成，每个节点又包含多个硬盘。

Ceph存储集群使用CRUSH算法确定数据的存储位置。

CRUSH算法将对象的ID映射到存储节点和介质上的位置，以实现负载均衡和故障恢复。

Ceph存储集群提供强一致性、高可靠性的存储服务，对于海量存储有着优异的性能和可扩展性。

二、Swift简介OpenStack Swift是一种分布式对象存储系统，旨在为云存储提供可扩展和高可靠性的存储服务。

Swift的设计原则是通过通过物理位置和命名空间的虚拟化将数据分散存储在多个存储节点上，从而实现高可用性和数据冗余。

Swift具有非常灵活的架构，它通过Ring实现数据的分发和复制。

Ring 是一个存储设备的逻辑描述，它包括设备的ID、位置和权重等信息。

Swift 使用Ring将对象分发到多个存储节点上，并在节点之间进行数据复制以实现数据冗余和容错能力。

Swift系统提供了强大的对象元数据管理、访问控制和数据访问接口等功能。

三、Ceph Swift原理Ceph Swift结合了Ceph和Swift的优点，提供了更强大和灵活的存储服务。

Ceph Swift基于Ceph存储系统构建，它使用Rados Gateway作为其对象存储接口。

Rados Gateway是Ceph存储系统的一部分，它充当了Ceph存储系统和任何符合Swift API标准的应用程序之间的中间层。

Ceph Swift支持Swift API的所有功能，并具有更强大的性能和可靠性。

ceph mds原理

ceph mds原理Ceph MDS原理什么是Ceph MDSCeph MDS（Metadata Server）是Ceph文件系统（CephFS）的一个关键组件，用于管理和维护文件系统的元数据信息。

它负责跟踪文件的位置、命名空间、访问权限等重要信息，并将这些信息存储在可扩展的分布式数据库中。

MDS的功能MDS具有以下主要功能：1.命名空间管理：MDS负责维护文件和目录在CephFS中的层次结构，保证命名空间的一致性和正确性。

2.元数据缓存：MDS通过使用内存缓存，在文件系统访问时提供快速的元数据查找和返回操作，减少磁盘IO的次数。

3.元数据日志：MDS记录元数据的变动操作，即元数据的创建、修改和删除等。

这些操作被写入日志，以便在故障恢复过程中进行恢复。

4.元数据负载均衡：MDS根据文件系统的使用情况，动态地将元数据分布到不同的存储节点上，以实现负载均衡和性能优化。

MDS工作原理Ceph MDS的工作原理可以概括为以下几个步骤：1.元数据服务器的选举：当启动一个新的Ceph集群时，需要选举一个主节点作为元数据服务器。

选举过程是通过Paxos算法实现的，选举出的主节点将负责管理CephFS的元数据。

2.元数据的命名空间管理：主节点负责管理文件系统的目录层次结构和文件名空间。

它维护了一个全局唯一的元数据树，记录了文件和目录的层次结构、属性和访问权限等信息。

3.元数据缓存的维护：主节点维护了一个元数据缓存，用于加速元数据的访问。

当客户端请求访问某个文件或目录时，主节点首先会在缓存中查找相应的元数据。

如果在缓存中找到了，就直接返回给客户端；否则，主节点需要从存储介质中读取对应的数据块，并将其存入缓存。

4.元数据日志的维护：主节点维护了一个元数据日志，用于记录元数据的变动操作。

每当有文件或目录的变动时，主节点将相应的操作写入日志。

这样，在发生故障时，可以通过回放日志来恢复丢失的元数据。

5.元数据的分布式存储：Ceph MDS采用了哈希算法将元数据分片存储到多个存储节点上。

ceph故障域原理

ceph故障域原理
Ceph是一种开源的分布式存储系统，具有高可靠性和高性能。

在Ceph中，故障域是一个重要的概念，它指的是系统中可能发生故
障的范围。

了解和理解Ceph的故障域原理对于设计和维护Ceph集
群至关重要。

Ceph集群通常由多个存储节点组成，这些节点可以是物理服务
器或虚拟机。

为了保证系统的高可用性，Ceph集群会将数据分布到
不同的故障域中，以防止单个故障域的故障影响整个系统的可用性。

在Ceph中，故障域可以是不同的层次，例如机架、数据中心、
区域等。

管理员可以根据实际情况设置不同的故障域，以便在发生
故障时能够最小化影响范围。

Ceph通过数据复制和数据分布的方式来实现故障域的原理。

数
据复制可以确保数据的冗余性，即使某个故障域发生故障，数据仍
然可以从其他故障域中获取。

数据分布则可以确保数据均匀地分布
在不同的故障域中，以提高系统的性能和可用性。

除了数据的复制和分布，Ceph还提供了故障域感知的调度策略。

这意味着Ceph可以根据故障域的状态来进行数据的调度，以确保系
统在发生故障时能够自动进行故障转移和恢复。

总之，Ceph的故障域原理是保证系统高可用性和可靠性的重要
基础。

通过合理设置故障域和使用故障域感知的调度策略，可以有
效地降低系统故障对业务的影响，从而提高系统的稳定性和可靠性。

ceph 故障域作用

ceph 故障域作用Ceph是一种开源的分布式存储系统，具有高可靠性和可扩展性。

在Ceph中，故障域是一种重要的概念，它对数据的可靠性和性能有着重要的影响。

故障域可以理解为一组物理或逻辑上相关联的节点或设备，当其中的一个节点或设备发生故障时，其他节点或设备可以继续提供服务。

在Ceph中，故障域常常用于实现数据的冗余和故障恢复。

故障域可以用于实现数据的冗余。

通过将数据复制到不同的故障域中，可以提高数据的可靠性。

当一个故障域中的节点或设备发生故障时，其他故障域中的节点或设备仍然可以提供数据服务，保证数据的可用性。

Ceph支持多种冗余策略，例如副本和EC（Erasure Coding），可以根据实际需求选择合适的故障域配置。

故障域还可以影响数据的性能。

在Ceph中，数据通常会被分布在不同的故障域中，这样可以实现数据的负载均衡。

当用户请求数据时，Ceph可以根据数据的位置和负载情况选择最近的故障域来提供服务，提高数据的访问速度。

此外，Ceph还支持故障域感知的数据迁移和重平衡，可以根据故障域的状态和负载情况动态调整数据的分布，提高系统的整体性能。

除了数据的冗余和性能，故障域还对系统的可维护性和可扩展性有着重要的影响。

通过将节点或设备组织成故障域，可以方便地进行故障诊断和维护。

当一个故障域中的节点或设备发生故障时，可以很容易地定位和修复故障，而不会影响其他故障域中的节点和设备。

此外，通过增加故障域，可以方便地扩展系统的容量和性能。

当需要增加存储空间或处理能力时，可以简单地添加新的故障域，而不需要对整个系统进行改动。

然而，故障域的设计和配置也需要考虑一些问题。

首先，故障域之间的距离和网络连接对数据的同步和传输有影响。

如果故障域之间的距离过远或网络连接不稳定，可能会导致数据同步延迟或传输失败。

因此，在设计故障域时需要考虑节点之间的距离和网络连接的可靠性，以保证数据的一致性和可用性。

故障域的大小和数量也需要合理配置。

ceph分布式存储多副本恢复机制

ceph分布式存储多副本恢复机制（最新版）目录1.Ceph 分布式存储的概念与基本架构2.多副本恢复机制的原理与实现3.多副本恢复机制的优缺点分析4.Ceph 分布式存储在实际应用中的案例与效果正文一、Ceph 分布式存储的概念与基本架构Ceph 是一种开源的分布式存储系统，旨在提供优秀的性能、可靠性和可扩展性。

它采用去中心化的设计理念，将数据分布在多个节点上，从而实现数据的高可靠性和容错能力。

Ceph 的架构主要包括三个部分：Ceph Monitor、Ceph OSD 和 Ceph Metadata。

其中，Ceph Monitor 负责监控整个集群的状态和性能，Ceph OSD 负责存储数据，Ceph Metadata 则负责存储元数据信息。

二、多副本恢复机制的原理与实现Ceph 分布式存储的多副本恢复机制是一种基于数据副本的数据保护和恢复策略。

在 Ceph 中，每个数据副本都会存储在不同的节点上，以确保数据的可靠性和容错能力。

当某个节点上的数据副本发生故障时，Ceph 会自动在其他节点上的副本中查找并恢复数据。

这种机制可以有效地保障数据的安全性和可靠性。

具体来说，Ceph 的多副本恢复机制主要包括以下几个步骤：1.数据写入：当客户端写入数据时，Ceph 会根据数据副本的数量和分布式策略，将数据同时写入多个节点上的副本。

2.数据读取：当客户端读取数据时，Ceph 会根据数据副本的分布式策略，从多个节点上的副本中读取数据，并根据副本的权重和可靠性等因素进行数据合并和校验。

3.数据恢复：当某个节点上的数据副本发生故障时，Ceph 会自动在其他节点上的副本中查找并恢复数据。

这种恢复机制可以有效地保障数据的安全性和可靠性。

三、多副本恢复机制的优缺点分析Ceph 分布式存储的多副本恢复机制具有以下几个优点：1.高可靠性：通过多个节点上的数据副本，可以有效地保障数据的安全性和可靠性。

2.高性能：通过数据分片和并行处理等技术，可以实现高并发和高性能的数据读写操作。

IP改变引起的Ceph monitor异常及OSD盘崩溃的总结

IP改变引起的Ceph monitor异常及OSD盘崩溃的总结公司搬家，所有服务器的ip改变。

对ceph服务器配置好ip后启动，发现monitor进程启动失败，monitor进程总是试图绑定到以前的ip地址，那当然不可能成功了。

开始以为服务器的ip设置有问题，在改变hostname、ceph.conf等方法无果后，逐步分析发现，是monmap中的ip地址还是以前的ip，ceph通过读取monmap来启动monitor进程，所以需要修改monmap。

但出现了上一篇文章中描述的一块osd盘挂掉的情况。

查了一圈，只搜到ceph的官网上说是ceph的一个bug。

无力修复，于是删掉这块osd，再重装：1.# service ceph stop osd.42.#不必执行ceph osd crush remove osd.43.# ceph auth del osd.44.# ceph osd rm 45.6.# umount /cephmp17.# mkfs.xfs -f /dev/sdc8.# mount /dev/sdc /cephmp19.#此处执行create无法正常安装osd10.# ceph-deploy osd prepare osd2:/cephmp1:/dev/sdf111.# ceph-deploy osd activate osd2:/cephmp1:/dev/sdf1完成后重启该osd，成功运行。

从Ceph看分布式系统故障检测 - CatKang的博客

从Ceph看分布式系统故障检测
节点的故障检测是分布式系统无无法回避的问题，集群需要感知节点的存活，并作出适当的调整。通常我们采用ቤተ መጻሕፍቲ ባይዱ心心跳的方方式来进行行故障检测，并认为能正常与外界保持心心跳的节点便能够正常提供服务。一一个好的故障检测策略应该能够做到：
及时：节点发生生异常如宕机或⺴网网络中断时，集群可以在可接受的时间范围内感知；适当的压力力：包括对节点的压力力，和对⺴网网络的压力力；容忍⺴网网络抖动扩散机制：节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群；
mon_osd_min_down_reporters(2): 最少需要多少来自自不同的 mon_osd_reporter_subtree_level的osd的错误报告
mon_osd_adjust_heartbeat_grace(true)：在计算确认OSD失效的时间阈值时，是否要考虑该OSD历史上的延迟，因此失效的时间阈值通常会大大于osd_heartbeat_grace 指定的值
osd_heartbeat_grace(20)：多久没有收到回复可以认为对方方已经down
OSD向Monitor汇报伙伴OSD失效
1. OSD发送错误报告
OSD周期性的检查failure_queue中的伙伴OSD失败信息；向Monitor发送失效报告，并将失败信息加入入failure_pending队列，然后将其从 failure_queue移除；收到来自自failure_queue或者failure_pending中的OSD的心心跳时，将其从两个队列中移除，并告知Monitor取消之前的失效报告；当发生生与Monitor⺴网网络重连时，会将failure_pending中的错误报告加回到 failure_queue中，并再次发送给Monitor。

一种国产麒麟私有云故障分析处理方法

0引言私有云平台系统由麒麟云计算平台和一套ceph 分布式存储组成，整个云平台部署架构如图1所示。

分布式存储为云计算平台提供存储服务，物理服务器通过存储交换机形成独立的存储网以3副本机制为麒麟云计算平台提供存储空间。

存储节点服务器的每块硬盘被设计为ceph 分布式存储的osd （即对象存储设备，ceph 管理的存储单元，在操作系统中表现为1个进程）。

ceph 分布式存储运行时的主要进程包括monitor 进程和osd 进程。

osd 在集群中有up 和down 两种状态，up 表示正常工作，down 表示离开集群[1]。

在软硬件例行检查中发现国产麒麟云平台分布式存储集群中多个osd 出现down ，云平台上部分虚拟服务器无法远程桌面访问，部分不能ping 通，能ping 通的虚拟服务器也无法通过ssh 协议登录。

分布式存储健康状态显示为HEALTH_ERR ，虚拟机无法正常使用，业务软件不能运行[2]。

1故障排查过程1.1docker 容器检查登录controller （控制）节点查看docker 服务进程，状态显示均正常，确定麒麟云计算平台docker 容器运行正常，问题初步定位为分布式存储服务异常。

1.2存储节点检查①查看分布式存储集群健康状态，显示为health_err ，进一步查看有7个osd down ，分布在5个ceph 节点上。

各osd down 初始时间如表1所示。

查看osd down 的日志如图2所示，显示心跳检测没有收到回复。

②手动启动状态为down 的osd （先操作compute1上的osd1），osd 未能成功启动，新增日志如图2所示，重启未能解决问题。

③检查分布式存储进程，并手动“杀掉”状态为down 的osd 进程。

再次启动osd 未有反应，日志依旧提示错误，如图3所示。

“杀掉”的osd 进程处于“僵尸”状态，尝试“杀掉”僵尸进程，操作系统卡死。

僵尸进程的父进程号为1，无法被“杀掉”。

Ceph分布式存储中遇到的问题和解决办法

Ceph分布式存储中遇到的问题和解决办法最近有很多朋友拿着一篇关于“ceph运维那些坑”的文章来找我，起初我并没有在意，毕竟对于一个“新物种”来说，存在质疑是再正常不过的。

不过，陆续有更多的合作伙伴甚至圈内同行来问我如何看待这篇文章时，我觉得做为一名Ceph开发和运维的技术者，理应站出来为Ceph说点什么。

首先，原作者分析Ceph运维中遇到的问题是真实存在的，甚至在实际的运维过程中还出现过其他更复杂的问题。

因为最初的Ceph只是社区提供的一套开源版，因而想要实现产品化需要趟过很多次“坑”，就像最早的安卓系统一样。

我想任何产品在一开始都难以做到十全十美，因为技术本身就是在发现问题与解决问题的道路上不断前进发展的。

不过，在这里我想澄清的事实是：连初涉Ceph的运维人员都能发现的问题，研究Ceph多年的资深技术人员们肯定也早已发现。

接下来我就根据那篇文章中提到的坑，来说一说在实际产品化过程中我们是如何解决它们的。

一、扩容问题Ceph本身基于Crush算法，具备了多种数据复制策略，可以选择在磁盘、主机、机柜等等位置附着。

例如：如果采取3副本的数据保护策略，就可以通过复制策略来决定这3个副本是否同时分布在不同的磁盘、不同的主机、不同的隔离域、不同的机柜等位置来保证部分硬件故障后数据安全性和服务运行不中断。

Ceph底层是用资源池（POOL）来实现数据逻辑隔离，往往我们会出现因容量或性能不足需要对资源池进行扩容的问题，但是在容量扩容过程中，势必会带来进行数据重新平衡的要求。

Ceph中数据以PG为单位进行组织，因此当数据池中加入新的存储单元（OSD）时，通过调整OSDMAP会带来数据重平衡。

正如文章所提到的，如果涉及到多个OSD的扩容是可能导致可用PG中OSD小于min_size，从而发生PG不可用、IO阻塞的情况。

为了尽量避免这种情况的出现，只能将扩容粒度变小，比如每次只扩容一个OSD或者一个机器、一个机柜（主要取决于存储隔离策略），但是这样注定会带来极大的运维工作量，甚至连扩容速度可能都赶不上数据增长速度。

Cephmonitor故障恢复探讨

Cephmonitor故障恢复探讨1 问题⼀般来说，在实际运⾏中，ceph monitor的个数是2n+1(n>=0)个，在线上⾄少3个，只要正常的节点数>=n+1，ceph的paxos算法能保证系统的正常运⾏。

所以，对于3个节点，同时只能挂掉⼀个。

⼀般来说，同时挂掉2个节点的概率⽐较⼩，但是万⼀挂掉2个呢？如果ceph的monitor节点超过半数挂掉，paxos算法就⽆法正常进⾏仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。

If there are not enough monitors to form a quorum, the ceph command will block trying to reach the cluster. In this situation, you need to getenough ceph-mon daemons running to form a quorum before doing anything else with the cluster.所以，（1）如果挂掉的2个节点⾄少有⼀个可以恢复，也就是monitor的元数据还是OK的，那么只需要重启ceph-mon进程即可。

所以，对于monitor，最好运⾏在RAID的机器上。

这样，即使机器出现故障，恢复也⽐较容易。

（2）如果挂掉的2个节点的元数据都损坏了呢？出现这种情况，说明⼈品不⾏，2台机器的RAID磁盘同时损坏，这得多背？肯定是管理员嫌⼯资太低，把机器砸了。

如何恢复呢？2 恢复其实，也没有其它办法，只能想办法将故障的节点恢复，但元数据已经损坏。

幸好还有⼀个元数据正常的节点，通过它可以恢复。

添加monitor的步骤：$ ceph mon getmap -o /tmp/monmap # provides fsid and existing monitor addrs$ ceph auth export mon. -o /tmp/monkey # mon. auth key$ ceph-mon -i newname --mkfs --monmap /tmp/monmap --keyring /tmp/monkey所以，只要得到monmap，就可以恢复monitor了。

记一次ceph集群的严重故障（转）

记⼀次ceph集群的严重故障（转）问题：集群状态，坏了⼀个盘，pg状态好像有点问题[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_WARN64 pgs degraded64 pgs stuck degraded64 pgs stuck unclean64 pgs stuck undersized64 pgs undersizedrecovery 269/819 objects degraded (32.845%)monmap e1: 1 mons at {ceph-1=192.168.101.11:6789/0}election epoch 6, quorum 0 ceph-1osdmap e38: 3 osds: 2 up, 2 in; 64 remapped pgsflags sortbitwise,require_jewel_osdspgmap v14328: 72 pgs, 2 pools, 420 bytes data, 275 objects217 MB used, 40720 MB / 40937 MB avail269/819 objects degraded (32.845%)64 active+undersized+degraded8 active+clean[root@ceph-1 ~]# ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-1 0.05846 root default-2 0.01949 host ceph-10 0.01949 osd.0 up 1.00000 1.00000-3 0.01949 host ceph-21 0.01949 osd.1 up 1.00000 1.00000-4 0.01949 host ceph-32 0.01949 osd.2 down 0 1.00000将osd.2的状态设置为outroot@ceph-1:~# ceph osd out osd.2osd.2 is already out.从集群中删除root@ceph-1:~# ceph osd rm osd.2removed osd.2从CRUSH中删除root@ceph-1:~# ceph osd crush rm osd.2removed item id 2 name 'osd.2' from crush map删除osd.2的认证信息root@ceph02:~# ceph auth del osd.2updatedumount报错[root@ceph-3 ~]# umount /dev/vdb1umount: /var/lib/ceph/osd/ceph-2: target is busy.(In some cases useful info about processes that usethe device is found by lsof(8) or fuser(1))kill掉ceph⽤户的占⽤[root@ceph-3 ~]# fuser -mv /var/lib/ceph/osd/ceph-2USER PID ACCESS COMMAND/var/lib/ceph/osd/ceph-2:root kernel mount /var/lib/ceph/osd/ceph-2ceph 1517 F.... ceph-osd[root@ceph-3 ~]# kill -9 1517[root@ceph-3 ~]# fuser -mv /var/lib/ceph/osd/ceph-2USER PID ACCESS COMMAND/var/lib/ceph/osd/ceph-2:root kernel mount /var/lib/ceph/osd/ceph-2[root@ceph-3 ~]# umount /var/lib/ceph/osd/ceph-2重新准备磁盘[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf osd prepare ceph-3:/dev/vdb1激活所有节点上的osd磁盘或者分区[root@ceph-deploy my-cluster]# ceph-deploy osd activate ceph-1:/dev/vdb1 ceph-2:/dev/vdb1 ceph-3:/dev/vdb1报错...[ceph-3][ERROR ] RuntimeError: command returned non-zero exit status: 1[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: /usr/sbin/ceph-disk -v activate --mark-init systemd --mount /dev/vdb1⼀怒之下关机重启[root@ceph-3 ~]# init 0Connection to 192.168.101.13 closed by remote host.Connection to 192.168.101.13 closed.重启之后，osd好了，但是pg的问题好像还没解决[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_WARN64 pgs degraded64 pgs stuck degraded64 pgs stuck unclean64 pgs stuck undersized64 pgs undersizedrecovery 269/819 objects degraded (32.845%)monmap e1: 1 mons at {ceph-1=192.168.101.11:6789/0}election epoch 6, quorum 0 ceph-1osdmap e53: 3 osds: 3 up, 3 inflags sortbitwise,require_jewel_osdspgmap v14368: 72 pgs, 2 pools, 420 bytes data, 275 objects5446 MB used, 55960 MB / 61406 MB avail269/819 objects degraded (32.845%)64 active+undersized+degraded8 active+clean[root@ceph-1 ~]# ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-1 0.03897 root default-2 0.01949 host ceph-10 0.01949 osd.0 up 1.00000 1.00000-3 0.01949 host ceph-21 0.01949 osd.1 up 1.00000 1.00000-4 0 host ceph-32 0 osd.2 up 1.00000 1.00000在ceph-1和ceph-2中加了⼀块硬盘，然后创建osd[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf osd create ceph-1:/dev/vdd ceph-2:/dev/vdd查看集群状态，发现pg数好像⼩了[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_WARN14 pgs degraded14 pgs stuck degraded64 pgs stuck unclean14 pgs stuck undersized14 pgs undersizedrecovery 188/819 objects degraded (22.955%)recovery 200/819 objects misplaced (24.420%)too few PGs per OSD (28 < min 30)monmap e1: 1 mons at {ceph-1=192.168.101.11:6789/0}election epoch 6, quorum 0 ceph-1osdmap e63: 5 osds: 5 up, 5 in; 50 remapped pgsflags sortbitwise,require_jewel_osdspgmap v14408: 72 pgs, 2 pools, 420 bytes data, 275 objects5663 MB used, 104 GB / 109 GB avail188/819 objects degraded (22.955%)200/819 objects misplaced (24.420%)26 active+remapped24 active14 active+undersized+degraded8 active+clean增加pg和pgp[root@ceph-1 ~]# ceph osd pool set rbd pg_num 128[root@ceph-1 ~]# ceph osd pool set rbd pgp_num 128状态就成error了......[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_ERR118 pgs are stuck inactive for more than 300 seconds118 pgs peering118 pgs stuck inactive128 pgs stuck uncleanrecovery 16/657 objects misplaced (2.435%)monmap e2: 2 mons at {ceph-1=192.168.101.11:6789/0,ceph-3=192.168.101.13:6789/0}election epoch 8, quorum 0,1 ceph-1,ceph-3osdmap e74: 5 osds: 5 up, 5 in; 55 remapped pgsflags sortbitwise,require_jewel_osdspgmap v14459: 136 pgs, 2 pools, 356 bytes data, 221 objects5665 MB used, 104 GB / 109 GB avail16/657 objects misplaced (2.435%)73 peering45 remapped+peering10 active+remapped8 active+clean[root@ceph-1 ~]# less /etc/ceph/ceph.co于是我⼜重启了三台osd机器，重启发现⼜有osd down了[root@ceph-1 ~]# ceph -s2018-07-25 15:18:17.207665 7fb4ec2ee700 0 -- :/1038496581 >> 192.168.101.12:6789/0 pipe(0x7fb4e8063fa0 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7fb4e805c610).faultcluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_WARN16 pgs degraded59 pgs stuck unclean16 pgs undersizedrecovery 134/819 objects degraded (16.361%)recovery 88/819 objects misplaced (10.745%)1/5 in osds are downmonmap e2: 2 mons at {ceph-1=192.168.101.11:6789/0,ceph-3=192.168.101.13:6789/0}election epoch 12, quorum 0,1 ceph-1,ceph-3osdmap e95: 5 osds: 4 up, 5 in; 43 remapped pgsflags sortbitwise,require_jewel_osdspgmap v14529: 136 pgs, 2 pools, 420 bytes data, 275 objects5668 MB used, 104 GB / 109 GB avail134/819 objects degraded (16.361%)88/819 objects misplaced (10.745%)77 active+clean39 active+remapped16 active+undersized+degraded4 active[root@ceph-1 ~]# ceph osd tree2018-07-25 15:22:25.573039 7fe5ff87c700 0 -- :/3787750993 >> 192.168.101.12:6789/0 pipe(0x7fe604063fd0 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7fe60405c640).faultID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-1 0.10725 root default-2 0.04388 host ceph-10 0.01949 osd.0 up 1.00000 1.000003 0.02440 osd.3 up 1.00000 1.00000-3 0.04388 host ceph-21 0.01949 osd.1 down 0 1.000004 0.02440 osd.4 up 1.00000 1.00000-4 0.01949 host ceph-32 0.01949 osd.2 up 1.00000 1.00000把坏盘out、rm、crush rm、auth del后，集群健康了[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_OKmonmap e2: 2 mons at {ceph-1=192.168.101.11:6789/0,ceph-3=192.168.101.13:6789/0}election epoch 12, quorum 0,1 ceph-1,ceph-3osdmap e102: 4 osds: 4 up, 4 inflags sortbitwise,require_jewel_osdspgmap v14597: 136 pgs, 2 pools, 356 bytes data, 270 objects5559 MB used, 86551 MB / 92110 MB avail136 active+clean换掉了坏盘，把新的盘重新加⼊ceph集群(扩容也是这样操作)[root@ceph-deploy my-cluster]# ceph-deploy disk list ceph-2[root@ceph-deploy my-cluster]# ceph-deploy disk zap ceph-2:vdb[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf osd create ceph-2:vdb:/dev/vdc1现在看是error[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_ERR13 pgs are stuck inactive for more than 300 seconds50 pgs degraded2 pgs peering1 pgs recovering17 pgs recovery_wait13 pgs stuck inactive23 pgs stuck uncleanrecovery 67/798 objects degraded (8.396%)monmap e2: 2 mons at {ceph-1=192.168.101.11:6789/0,ceph-3=192.168.101.13:6789/0}election epoch 12, quorum 0,1 ceph-1,ceph-3osdmap e110: 5 osds: 5 up, 5 inflags sortbitwise,require_jewel_osdspgmap v14633: 136 pgs, 2 pools, 356 bytes data, 268 objects5669 MB used, 104 GB / 109 GB avail67/798 objects degraded (8.396%)79 active+clean32 activating+degraded17 active+recovery_wait+degraded5 activating2 peering1 active+recovering+degradedclient io 0 B/s wr, 0 op/s rd, 5 op/s wr过了⼀会看就完全正常了[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_OKmonmap e2: 2 mons at {ceph-1=192.168.101.11:6789/0,ceph-3=192.168.101.13:6789/0}election epoch 12, quorum 0,1 ceph-1,ceph-3osdmap e110: 5 osds: 5 up, 5 inflags sortbitwise,require_jewel_osdspgmap v14666: 136 pgs, 2 pools, 356 bytes data, 267 objects5669 MB used, 104 GB / 109 GB avail136 active+clean问题：增加mon报错[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf mon create ceph-2[ceph-2][ERROR ] admin_socket: exception getting command descriptions: [Errno 2] No such file or directory[ceph-2][WARNIN] neither `public_addr` nor `public_network` keys are defined for monitors[root@ceph-2 ~]# less /var/log/ceph/ceph-mon.ceph-2.log2018-07-25 15:52:02.566212 7efeec7d9780 -1 no public_addr or public_network specified, and mon.ceph-2 not present in monmap or ceph.conf原因：ceph.conf⾥⾯没有配置public_network[global]fsid = 72f44b06-b8d3-44cc-bb8b-2048f5b4acfemon_initial_members = ceph-1,ceph-2,ceph-3mon_host = 192.168.101.11,192.168.101.12,192.168.101.13auth_cluster_required = cephxauth_service_required = cephxauth_client_required = cephxosd pool default size = 2修改ceph.conf⽂件[root@ceph-deploy my-cluster]# vi ceph.conf[global]fsid = 72f44b06-b8d3-44cc-bb8b-2048f5b4acfemon_initial_members = ceph-1,ceph-2,ceph-3mon_host = 192.168.101.11,192.168.101.12,192.168.101.13auth_cluster_required = cephxauth_service_required = cephxauth_client_required = cephxosd pool default size = 2public_network = 192.168.122.0/24cluster_network = 192.168.101.0/24推送新的配置⽂件⾄各个节点[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf config push ceph-1 ceph-2 ceph-3增加ceph-2为mon[root@ceph-deploy my-cluster]# ceph-deploy mon add ceph-2添加成功后发现，mon集群中ceph-2的ip跟其他的不⼀样，按照配置⽂件，应该跟该ceph-1、ceph-3的⽹段为122[root@ceph-1 ~]# ceph -scluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfehealth HEALTH_OKmonmap e3: 3 mons at {ceph-1=192.168.101.11:6789/0,ceph-2=192.168.122.12:6789/0,ceph-3=192.168.101.13:6789/0}election epoch 14, quorum 0,1,2 ceph-1,ceph-3,ceph-2osdmap e110: 5 osds: 5 up, 5 inflags sortbitwise,require_jewel_osdspgmap v14666: 136 pgs, 2 pools, 356 bytes data, 267 objects5669 MB used, 104 GB / 109 GB avail136 active+clean所以，我修改ceph.conf中mon节点的ip段为122[root@ceph-deploy my-cluster]# vi ceph.conf[global]fsid = 72f44b06-b8d3-44cc-bb8b-2048f5b4acfemon_initial_members = ceph-1,ceph-2,ceph-3mon_host = 192.168.122.11,192.168.122.12,192.168.122.13auth_cluster_required = cephxauth_service_required = cephxauth_client_required = cephxosd pool default size = 2public_network = 192.168.122.0/24cluster_network = 192.168.101.0/24再来⼀波推送[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf config push ceph-1 ceph-2 ceph-3删除两个mon[root@ceph-deploy my-cluster]# ceph-deploy mon destroy ceph-1 ceph-3然后整个集群都不好了[root@ceph-1 ~]# ceph -s2018-07-25 16:35:21.723736 7f47dedfb700 0 -- 192.168.122.11:0/4277586904 >> 192.168.122.13:6789/0 pipe(0x7f47c8000c80 sd=4 :0 s=1 pgs=0 cs=0 l=1 c=0x7f47c8001f90).fault with nothing to send, going to standby2018-07-25 16:35:27.723930 7f47dedfb700 0 -- 192.168.122.11:0/4277586904 >> 192.168.122.11:6789/0 pipe(0x7f47c8005330 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7f47c8002410).fault with nothing to send, going to standby2018-07-25 16:35:33.725130 7f47deffd700 0 -- 192.168.122.11:0/4277586904 >> 192.168.122.13:6789/0 pipe(0x7f47c8005330 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7f47c80046e0).fault with nothing to send, going to standby[root@ceph-1 ~]# ceph osd tree2018-07-25 16:35:21.723736 7f47dedfb700 0 -- 192.168.122.11:0/4277586904 >> 192.168.122.13:6789/0 pipe(0x7f47c8000c80 sd=4 :0 s=1 pgs=0 cs=0 l=1 c=0x7f47c8001f90).fault with nothing to send, going to standby2018-07-25 16:35:27.723930 7f47dedfb700 0 -- 192.168.122.11:0/4277586904 >> 192.168.122.11:6789/0 pipe(0x7f47c8005330 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7f47c8002410).fault with nothing to send, going to standby2018-07-25 16:35:33.725130 7f47deffd700 0 -- 192.168.122.11:0/4277586904 >> 192.168.122.13:6789/0 pipe(0x7f47c8005330 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7f47c80046e0).fault with nothing to send, going to standby好像也加不回去[root@ceph-deploy my-cluster]# ceph-deploy mon add ceph-1 ceph-3[ceph-1][WARNIN] 2018-07-25 16:37:52.760218 7f06739b9700 0 -- 192.168.122.11:0/2929495808 >> 192.168.122.11:6789/0pipe(0x7f0668000c80 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7f0668005c20).fault with nothing to send, going to standby[ceph-1][WARNIN] 2018-07-25 16:37:55.760830 7f06738b8700 0 -- 192.168.122.11:0/2929495808 >> 192.168.122.13:6789/0pipe(0x7f066800d5e0 sd=4 :0 s=1 pgs=0 cs=0 l=1 c=0x7f066800e8a0).fault with nothing to send, going to standby[ceph-1][WARNIN] 2018-07-25 16:37:58.760748 7f06739b9700 0 -- 192.168.122.11:0/2929495808 >> 192.168.122.11:6789/0pipe(0x7f0668000c80 sd=4 :0 s=1 pgs=0 cs=0 l=1 c=0x7f066800be40).fault with nothing to send, going to standby不嫌事⼤，把最后⼀个mon也删掉[root@ceph-deploy my-cluster]# ceph-deploy mon destroy ceph-2[root@ceph-deploy my-cluster]# ceph-deploy new ceph-1 ceph-2 ceph-3[root@ceph-deploy my-cluster]# ceph-deploy --overwrite-conf mon create-initial[ceph-1][ERROR ] "ceph auth get-or-create for keytype admin returned 22[ceph-1][DEBUG ] Error EINVAL: unknown cap type 'mgr'[ceph-1][ERROR ] Failed to return 'admin' key from host ceph-1[ceph-2][ERROR ] "ceph auth get-or-create for keytype admin returned 22[ceph-2][DEBUG ] Error EINVAL: unknown cap type 'mgr'[ceph-2][ERROR ] Failed to return 'admin' key from host ceph-2[ceph-3][ERROR ] "ceph auth get-or-create for keytype admin returned 22[ceph-3][DEBUG ] Error EINVAL: unknown cap type 'mgr'[ceph-3][ERROR ] Failed to return 'admin' key from host ceph-3[ceph_deploy.gatherkeys][ERROR ] Failed to connect to host:ceph-1, ceph-2, ceph-3[ceph_deploy.gatherkeys][INFO ] Destroy temp directory /tmp/tmpnPWk4d[ceph_deploy][ERROR ] RuntimeError: Failed to connect any mon[root@ceph-deploy my-cluster]# ceph-deploy mon add ceph-1[ceph-1][INFO ] monitor: mon.ceph-1 is running[root@ceph-deploy my-cluster]# ceph-deploy mon add ceph-2[ceph-2][INFO ] monitor: mon.ceph-2 is running[root@ceph-deploy my-cluster]# ceph-deploy mon add ceph-3[ceph-3][INFO ] monitor: mon.ceph-3 is running[root@ceph-1 ceph-ceph-1]# ceph -s2018-07-25 20:42:07.965513 7f1482a91700 0 librados: client.admin authentication error (1) Operation not permittedError connecting to cluster: PermissionError通常我们执⾏ceph -s 时，就相当于开启了⼀个客户端，连接到 Ceph 集群，⽽这个客户端默认是使⽤ client.admin 的账户密码登陆连接集群的，所以平时执⾏的ceph -s 相当于执⾏了 ceph -s --name client.admin --keyring /etc/ceph/ceph.client.admin.keyring。

ceph心跳丢失问题分析

ceph心跳丢失问题分析
谷忠言
Agenda
• • • • • 现象/问题 Ceph 心跳原理 Filestore 线程模型 ceph集群bjtp-ssd实例分析总结
现象/问题
• Test case:
– 800 or 1200 vms run fio, 64k 顺序写
• 现象:
– Monitor收到报告，有osd failed.
Bjtp集群实例分析：case1
• 为什么filestore op_tp处理一个op 要花74s?
Bjtp集群实例分析：case2
• journal write_aio_bl() slow， and filestore write() slow，出去的op慢，also blocking sync_entry(不能pause op_tp) 导致限流不能解除。
• osd.707 10.205.194.53:6801/96651 failed (3 reports from 3 peers after 20.000106 >= grace 20.000000)
– 但osd.707 还在up and running 的状态 – 此时集群有部分object处于degraded状态 – 保持压力，持续degraded，停止压力，自行恢复
• OSD::osd_op_tp
– Filestore 限流
• Filejournal::writeq
– Journal FULL – aio 限流
• FileStore::op_tp
– op_tp互相的锁竞争 – 被sync_thread pause
• 以上线程处理的队列为空，睡眠 • Filestore:sync_thread

ceph扩容注意事项

ceph扩容注意事项一、引言ceph是一款开源的分布式存储系统，广泛应用于大规模的云计算环境中。

在实际使用中，随着数据量的增长，我们可能需要对ceph集群进行扩容以满足需求。

本文将介绍ceph扩容的注意事项，帮助读者避免一些常见的错误和问题。

二、了解ceph集群架构在进行ceph扩容之前，首先需要了解当前ceph集群的架构。

ceph 集群由多个存储节点（OSD）组成，这些节点通过监控器（MON）进行协调和管理。

在扩容过程中，需要考虑集群中各个组件的负载情况，以便合理规划扩容策略。

三、确定扩容需求在进行ceph扩容之前，需要明确扩容的具体需求。

这包括需要扩容的存储容量、带宽要求、IOPS要求等。

根据这些需求，可以选择不同的扩容方案，比如增加存储节点、增加存储介质等。

四、选择合适的扩容方案根据实际需求，选择合适的扩容方案非常重要。

常见的扩容方案包括：1. 增加存储节点：通过增加存储节点来扩大ceph集群的存储容量。

在选择存储节点时，需要考虑节点的性能和可靠性，以及与现有节点的兼容性。

2. 增加存储介质：通过增加存储介质来提高ceph集群的性能。

可以选择更高速的硬盘或固态硬盘来替换或增加现有的存储介质。

3. 调整数据分布策略：通过调整ceph集群的数据分布策略，将数据均匀分布到不同的存储节点上，以提高存储性能和可靠性。

五、规划扩容过程在进行ceph扩容之前，需要进行详细的规划。

这包括：1. 网络规划：确保扩容过程中网络的稳定和可靠性，避免网络拥堵或故障对扩容过程的影响。

2. 数据迁移：如果需要调整数据分布策略或增加存储介质，需要进行数据迁移。

在进行数据迁移时，需要确保数据的完整性和一致性。

3. 高可用性规划：在扩容过程中，需要确保ceph集群的高可用性。

可以通过增加冗余节点或使用多活架构等方式来提高集群的可靠性。

六、备份数据在进行ceph扩容之前，务必备份重要数据。

扩容过程中可能会涉及到数据迁移和节点的增加或替换，这些操作都有一定的风险。

ceph crush规则

ceph crush规则
Ceph Crush规则是Ceph存储系统中的一个重要组成部分，它定义了数据在存储集群中的分布方式。

Crush规则的设计目的是为了提高数据的可靠性和可用性，同时也可以提高存储系统的性能和扩展性。

Crush规则的核心思想是将数据分散到存储集群中的多个节点上，以避免单点故障和数据丢失。

Crush规则通过一系列算法和策略来实现数据的分布和复制，其中包括数据的散列、数据的复制、数据的迁移等。

Crush规则的实现需要考虑多个因素，包括存储节点的数量、存储节点的性能、存储节点的位置等。

在Crush规则中，每个存储节点都被赋予了一个权重值，这个权重值反映了存储节点的性能和可靠性。

Crush规则还可以根据存储节点的位置来进行数据的分布，以避免数据在同一地区的存储节点上集中存储。

Crush规则还可以实现数据的复制和迁移。

在Crush规则中，数据可以被复制到多个存储节点上，以提高数据的可靠性和可用性。

同时，Crush规则还可以实现数据的迁移，以平衡存储集群中的负载和提高存储系统的性能。

Ceph Crush规则是Ceph存储系统中的一个重要组成部分，它可以实现数据的分布、复制和迁移，以提高存储系统的可靠性、可用性
和性能。

在实际应用中，我们需要根据存储集群的实际情况来设计和调整Crush规则，以达到最佳的存储效果。