系统架构运维经验分享
您可以使用ceph daemon osd.ID perf dump命令来检查 WAL/DB 分区是否即将填满及溢出。 slow_used_bytes 值显示即将溢出的数据量： # ceph daemon osd.1 perf dump | jq ‘.bluefs’ { “db_total_bytes”: 80014729216, #block.db总大小 “db_used_bytes”: 52428800, #block.db使用 “wal_total_bytes”: 8589930496, #bl
继续阅读 >>## 安装前优化 在安装Ceph集群之前，对系统进行优化可以显著提高集群的性能和稳定性。以下是一些关键的优化措施： ### 内核参数优化 “`bash # 创建并编辑内核参数配置文件 cat > /etc/sysctl.d/90-ceph.conf << EOF # 文件系统和I/O优化 fs.aio-max-nr = 1048576 fs.file-max = 6553600 # 进程和内存优化 kernel.pid_max = 4194304 vm.max_map_count = 262144 vm.swappiness = 10 vm.dirty_ratio
继续阅读 >>Ceph 设计为在商用硬件上运行，这使得构建和维护PB级数据集群在经济上可行。在规划集群硬件时，您需要平衡许多考虑因素，包括故障域和潜在的性能问题。硬件规划应包括将 Ceph 守护进程和其他使用 Ceph 的进程分布在多台主机上。通常，我们建议在为该类型的守护进程配置的主机上运行特定类型的 Ceph 守护进程。我们建议将另外的其他主机用于使用您的数据集群的进程（例如，OpenStack、CloudStack 等）。 CPU CephFS 元数据服务器是 CPU 密集型的，因此它们应该具有强大的处理能力（例如，四核或更好的 CPU）并受益于更高的时钟频率（频率以 GHz 为单位）。Ceph OS
继续阅读 >>1、Ceph的起源与发展 Ceph项目起源于 2004年，是其创始人 SageWeil在加州大学 SantaCruz分校攻读博士期间的研究课题，系统最初设计目标为提供一款基于 POSIX、没有单点故障、大规模的分布式文件存储系统。所谓“大规模”和“分布式”，是指存储系统至少能够承载PB级别的数据，并且由成千上万的存储节点组成。大数据技术迅猛发展的今天，PB 级数据存储早已不是一个可以激动人心的系统设计目标，但应该指出，Ceph项目起源于2004 年，那是一个商用处理器以单核为主流、常见硬盘容量不足百 GB的年代，这和如今 CPU动辄 20核、40线程，还要双处理器、单块硬盘存储容量1
继续阅读 >>1、收到异常情况如下: health: HEALTH_ERR 2 scrub errors Possible data damage: 1 pg inconsistent 2、查看详细信息 ceph health detail HEALTH_ERR 2 scrub errors; Possible data damage: 1 pg inconsistent OSD_SCRUB_ERRORS 2 scrub errors PG_DAMAGED Possible data damage: 1 pg inconsistent pg 2.2f5 is active+clean+inconsisten
继续阅读 >>已有的git开源项目基础上做了一下针对性的优化和功能增强。 此监控插件功能能够满足项目的基本监控需求的。 项目地址： https://github.com/BodihTao/ceph-zabbix 主要改进： 采用 zabbix-agent(active) 模式，效率更高 采集脚本多机部署，数据发送到同一HOST，避免单点风险 增加支持 read/write iops item； 增加iops超高和ceph err告警 效果图： 安装配置也很简单，在已有的zabbix agent 上稍作修改 1. 把ceph-status.sh文件拷贝到zabbix_agent目录
继续阅读 >>