ceph

在CentOS 7 安装Calamari 2016年04月17日 18:59:06 lizhongwen1987 阅读数 8055 更多 分类专栏： Ceph 版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/lzw06061139/article/details/51174588 Ceph是一款开源的SDS软件，对于开源安装好可以只是完成了第一步，后面的监控运维才是重点；要想直观的了解集群的运行状态，监控软件也就必不可少了，而对于Ceph的监控用得比较多的有Zabbix，inkScope，Calamari等。下文将详细说明Calamari在CentOS 7上的安装过程。 获取Calamari源码包 #> git clone https://github.com/ceph/calamari.git #> git clone https://github.com/ceph/calamari-clients.git #> git clone https://github.com/ceph/Diamond 构建calamari server的rpm包 #> cd calamari #> yum remove prelink //避免安装时出现cpio Dismatch 错误 #

PG 当Ceph 集群接收到数据存储的请求时，它被分散到各个 PG 中。然而， CRUSH 首先将数据分解成 一组对象，然后根据对象名称、复制级别和系统中总的 PG 数目等信息执行散列操作，再将结果生成 PG ID。 PG 是一组对象的逻辑集合，通过复制它到不同的 OSD 上来提供存储系统的可靠性。 根据 Ceph 池的复制级别，每个 PG 的数据会被复制并分发到 Ceph集群的多个 OSD上。 可以将 PG 看成一个逻辑容器，这个容器包含多个对象，同时这个逻辑容器被映射到多个 OSD上。 PG 是保障 Ceph 存储系统的可伸缩性和性能必不可少的部分。 没有 PG ，在成千上万个 OSD 上管理和跟踪数以百万计的对象的复制和传播是相当困难的。 没有 PG 情况下管理这些对象所消耗的计算资源也是噩梦。 与独立的管理每一个对象不同的是，我们的系统只管理包含大量对象的 PG。 这使得 Ceph 成为一个更易于管理和更易上手的系统。 每个 PG 需要一定的系统资源(如 CPU 和内存)，因为每个 PG 需要管理多个对象 。因此应该精心计算集群中 PG 的数量 。一般来说，增加集群 PG 的数量能够降低每个 OSD 上的负载，但是应该以规范的方式进行增加， 建议每个 OSD上放置 50 - 100个PG。 这是为了避免 PG 占用 OSD 节点太多的资源。 随着存储数据的增加

ceph 网络配置 9. 分离 public network 和 cluster network 9.1 分离的好处 （1）提高性能：消除副本创建、数据恢复和再平衡对 public network 的压力；增强 OSD 心跳网络的可靠性。 （2）安全性：使用一个彻底与外网分离的内部网络作为 cluster network，可以防止比如 DDOS 这样的网络攻击。 更多信息，请参阅 NETWORK CONFIGURATION REFERENCE 。 9.2 分离的方法 （1）配置网络 给每个 OSD 节点增加一块网卡，它的连接方式为 “内部网络”；在虚机内配置静态IP地址，网段为 192.168.1.100/24 （其实用不了这么大的网段）. （2）在 ceph1 上修改 ceph.conf 文件 [global] ... public network = 192.168.56.100/24 cluster network = 192.168.1.100/24 [mon] [mon.ceph1] # MON 守护进程只在public network 内 host = ceph1 mon addr = 192.168.56.102:6789 [osd] osd journal size = 500 osd crush update on start = false [osd.3]

calamari-common 结构图 config.py 此文件定义了CalamariConfig类，用于读取calamari的配置文件，默认是"/etc/calamari/calamari.conf" salt_wrapper.py 定义了SaltEventSource类，此类用于处理salt服务的 MasterEvent类的关闭和重连接 types.py 此文件里包含一些对ceph概念的对象封装，会将ceph的json数据转成python对象 定义了:SyncObject，OsdMap,MdsMap等类 SyncObject ：(VersionedSyncObject，OsdMap，MdsMap等类的基类) ceph集群的一个对象类，calamari server对ceph集群的一个复制 将json序列化数据对象包在python对象里 －用类似id-to-entry字典的东西来装饰 －此类有个通用方式供查看对象的版本 util.py 此文件定义了一个叫memoize的装饰器，在types.py的OsdMap类里用到 calamari-web 结构图 conf 结构图 Cthulhu 结构图 manager cluster_monitor.py SyncObjects: 　此类作用->版本化对象的数据 ClusterMonitor： 　此类作用->远程管理ceph集群 ，

############在线调整ceph RBD 大小########## Ceph 支持自动精简配置的块设备，也就是说 只有当把数据存储到这个块设备时，才 会真正地使用物理存储空间，ceph RADOS 设备非常灵活，你可以自由地增加或者减少RBD的容量 当然，这需要底层的文件系统也支持调整容量。高级文件系统(例如 XFS ，Btrfs，EX ZFS）都支持在指定条件下调整文件系统容量。 #（1）客户端中查看remote_rbd71容量 [root@zabbix71 /]# rbd --image remote_rbd71 info rbd image 'remote_rbd71': size 100 GiB in 25600 objects order 22 (4 MiB objects) snapshot_count: 0 id: 148fdf5968ea2 block_name_prefix: rbd_data.148fdf5968ea2 format: 2 features: layering, exclusive-lock op_features: flags: create_timestamp: Mon Aug 26 15:23:16 2019 access_timestamp: Mon Aug 26 15:23:16 2019 modify_timestamp:

#创建rdb池子 [root@node140 osd]# ceph osd pool create rbd 128 #查看已经创建的pools池 [root@node140 osd]# ceph osd lspools 1 rdb #初始化pool [root@node140 osd]# rbd pool init rbd #ceph集群中创建remote_rbd71镜像 [root@node140 osd]# rbd create remote_data1 --size 100G --image-feature layering [root@node140 osd]# rbd create remote_rbd71 --size 100G --image-feature layering #查看rbd [root@node140 /]# rbd ls -l NAME SIZE PARENT FMT PROT LOCK rbd_data1 10 GiB 2 remote_rbd71 100 GiB 2 excl #查看镜像详细信息 [root@node140 /]# rbd --image rbd_data1 info #############ceph集群本地使用RBD############## #映射到本地，就可以翔本地硬盘一样使用了 [root@node140 osd]#

前言 ceph的可视化方案很多，本篇介绍的是比较简单的一种方式，并且对包都进行了二次封装，所以能够在极短的时间内构建出一个可视化的监控系统 本系统组件如下： ceph-jewel版本 ceph_exporter的jewel版本 prometheus的2.3.2版本 grafana的grafana-5.2.1版本 Ceph grafana的插件- Clusterby Cristian Calin 适配的系统为centos7 资源如下： http://static.zybuluo.com/zphj1987/jiwx305b8q1hwc5uulo0z7ft/ceph_exporter-2.0.0-1.x86_64.rpm http://static.zybuluo.com/zphj1987/1nu2k4cpcery94q2re3u6s1t/ceph-cluster_rev1.json http://static.zybuluo.com/zphj1987/7ro7up6r03kx52rkwy1qjuwm/prometheus-2.3.2-1.x86_64.rpm http://7xweck.com1.z0.glb.clouddn.com/grafana-5.2.1-1.x86_64.rpm 以上资源均可以直接用wget进行下载，然后直接安装 监控的架构介绍 通过ceph

一、前提准备 两台 Linux 服务器（主机名分别为ceph-iscsi-node1、ceph-iscsi-node2），作为iscsi网关，可以是集群中的主机。 一台 Linux 主机，作为 Linux 系统下的客户端。 一台 Windows 主机，作为 Windows 系统下的客户端。 二、配置ceph-iscsi网关 修改osd配置 shell> cat /etc/ceph/ceph.conf [osd] osd heartbeat grace = 20 osd heartbeat interval = 5 新建repo文件（已有ceph iscsi rpm包可跳过该步） cat /etc/yum.repo.d/iscsi.repo [ceph-iscsi] name=Ceph-iscsi baseurl=https://4.chacra.ceph.com/r/ceph-iscsi/master/88f3f67981c7da15448f140f711a1a8413d450b0/centos/7/flavors/default/noarch/ priority=1 gpgcheck=0 [tcmu-runner] name=tcmu-runner baseurl=https://3.chacra.ceph.com/r/tcmu-runner/master

分布式文件系统: 分布式文件系统 (Distributed File System) 是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机 / 服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以 " 发表 " 一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地 驱动器 一样。（服务器间的数据访问从一对多变为多对多） （1）原始的文件管理系统图： 一、MooseFS(MFS)文件系统 MFS 文件系统结构 : （1）包含 4 种角色 : 管理服务器 managing server (master) 元数据日志服务器 Metalogger server （ Metalogger ） 数据存储服务器 data servers (chunkservers) 客户机挂载使用 client computers （2） 4 种角色作用 : 管理服务器 : 负责各个数据存储服务器的管理 , 文件读写调度 , 文件空间回收以及恢复 . 多节点拷贝 元数据日志服务器 : 负责备份 master 服务器的变化日志文件，文件类型为 changelog_ml.*.mfs ，以便于在 master server 出问题的时候接替其进行工作

标签（空格分隔）： ceph，ceph运维，pg 如果集群状态是HEALTH_ERR 并且有pgs inconsistent，需要进行如下操作： 1. 通过下面的命令查看哪些pg状态不一致： # ceph pg dump|grep inconsistent 2. 根据输出的pg id(如：1.23)进行一致性检查： [root@node3 ~]# ceph pg scrub 1.23 instructing pg 1.23 on osd.5 to scrub 或者，进行深度的一致性检查： [root@node3 ~]# ceph pg deep-scrub 1.23 instructing pg 1.23 on osd.5 to deep-scrub 3. 最后修复该pg： [root@node3 ~]# ceph pg repair 1.23 instructing pg 1.23 on osd.5 to repair 把所有不一致的pg修复完成后，最后确认集群状态 4. 确认集群状态： [root@node3 ~]# ceph -s cluster: id: b8b4aa68-d825-43e9-a60a-781c92fec20e health: HEALTH_OK services: mon: 1 daemons, quorum node1 mgr: node1(active