ceph

重置cephfs 清理现有cephfs 所有文件，重建空间： 清理删除 cephfs 关闭所有mds服务 systemctl stop ceph-mds@$HOSTNAME systemctl status ceph-mds@$HOSTNAME 查看cephfs 信息 ## ceph fs ls name: leadorfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ] ## ceph mds stat e392: 0/1/1 up, 1 failed ## ceph mon dump dumped monmap epoch 1 设置mds状态为失败 ceph mds fail 0 删除mds文件系统 ceph fs rm leadorfs --yes-i-really-mean-it 删除元数据文件夹 ceph osd pool delete cephfs_metadata cephfs_metadata --yes-i-really-really-mean-it ceph osd pool delete cephfs_data cephfs_data --yes-i-really-really-mean-it 再次查看集群状态 ## ceph mds stat e394: ## eph mds dump

文章目录 1.存储文件的大小 2.存储类型：块存储和对象存储 3.对象存储的概念 5.对象存储和文件系统存储区别 1.存储文件的大小 HDFS、HBase、Hive不太适合存文档、图片大小的文件，HDFS适用于存大文件。 SWIFT：处理几个G的大文件性能上可能会比HDFS差，因为没有条带化。 但遇到很多几兆、几十兆的，这些文件的存储，HDFS就不如SWIFT。 所以对于日常文件的单独处理用SWIFT，集中处理如果达到G级用HDFS。 2.存储类型：块存储和对象存储 如果只要用对象存储，就选择SWIFT；如果只要用块存储，那就Ceph; 既要用对象存储又要用块存储的场合，是用SWIFT还是Ceph呢? （ 1 ）如果节点数量很大，推荐用Ceph单独做块，用SWIFT做对象存储，因为在节点数量较大时，Ceph的维护成本比SWIFT要高得多， 大多数场景实际应用的时候会发现，大部分数据都可以放到对象存储上 ; 2 ) 如果节点数量少，那就用Ceph统一搞定，因为一般认为生产环境中最小的分布式存储应当有五个节点，所以，如果节点数量 少于十个或者刚到十来个，那构建两个分布式存储显然是不理想的 ( 考虑到空间划分问题 ) ; 3 ) 如果团队里有牛人能轻松解决Ceph大规模部署问题，那就果断用Ceph ; 4 ) 如果希望对象存储能够和OpenStack其他项目无缝结合，如果希望实现多租户

Ceph分布式存储安装 前言 参照官方文档中的快速安装，结合国内环境，将相关安装源修改为国内镜像源提高安装速度。 http://docs.ceph.org.cn/start/ 基础系统环境 添加阿里云YUM源 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo 更新系统 yum update -y``` ### 关闭防火墙、SELinux systemctl stop firewalld && systemctl disable firewalld setenforce 0 sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config ### 添加hosts主机名解析（集群采用四台虚拟机） 四台机器均添加 echo "192.168.5.191

ceph s3cmd的命令 问题： 1. 使用access_key和secret_key获取的对象url,会缓存在浏览器disk cache中,导致每次第二次访问资源的时候，会报no-cors的错误 2. 浏览器获取数据时，会显示（from disk cache） 针对问题2，调研 强缓存 强缓存 强缓存：不会向服务器发送请求，直接从缓存中读取资源，在 chrome 控制台的 Network 选项中可以看到该请求返回 200 的状态码，并且 Size 显示 from disk cache 或 from memory cache。强缓存可以通过设置两种 HTTP Header 实现：Expires 和 Cache-Control。 1.Expires 缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说，Expires=max-age + 请求时间，需要和 Last-modified 结合使用。Expires 是 Web 服务器响应消息头字段，在响应 http 请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。 Expires 是 HTTP/1 的产物，受限于本地时间，如果修改了本地时间，可能会造成缓存失效。Expires: Wed, 22 Oct 2018 08:41:00 GMT表示资源会在 Wed, 22 Oct 2018 08

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 快速上手 官网地址： https://rook.io/ 项目地址： https://github.com/rook/rook 安装集群 准备osd存储介质 硬盘符号 大小 作用 sdb 50GB OSD Data sdc 50GB OSD Data sdd 50GB OSD Data sde 50GB OSD Metadata > 安装前使用命令 lvm lvs , lvm vgs 和 lvm pvs 检查上述硬盘是否已经被使用，若已经使用需要删除，且确保硬盘上不存在分区和文件系统 确保开启内核rbd模块并安装lvm2 modprobe rbd yum install -y lvm2 安装operator git clone --single-branch --branch release-1.2 https://github.com/rook/rook.git cd rook/cluster/examples/kubernetes/ceph kubectl create -f common.yaml kubectl create -f operator.yaml 安装ceph集群 --- apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name:

目录 一、背景介绍 二、 解决过程 一、背景介绍 ceph 版本为L版，集群由于异常断电，导致文件丢失，ceph mon 数据文件store.db/目录下的sst 文件丢失，所以无法正常启动。 本集群有三台mon节点，其中有一台mon 节点的服务可以正常启动，另外两台无法正常启动。 二、 解决过程 因为判断可能出现文件丢失导致的mon无法启动，所以决定重做另两台mon来解决问题 1、本环境中control3的mon是好的，control1和control2是坏的 在control3上导出monmap [root@control3 ~]monmaptool --create --clobber --fsid 45b34caa-83b8-4c36-833b-544bba873456 --add control3 172.16.12.43:6789 --add control1 172.16.12.41:6789 --add control2 172.16.12.42:6789 /tmp/monmap //导出monmap,好的节点写再前面，后面把所有的坏的节点加上即可。 2、将control1 和control2节点上的/var/lib/ceph/mon目录删掉，因为仅仅是文件丢失，并不是认证出现问题，原有的/etc/ceph/目录没有删除。 3、将keyring 文件传到其他节点上

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Ceph的一次不健康状态 环境：三台机器bdc212,bdc213，bdc213，每台机器2个osd，三副本，另外每台机器都是双网络，分别为192.168.8.0网段ip和192.168.12.0网段。 刚刚完成安装，测试集群重启，在bdc212的osd重启之后发现集群状态一直为ERR，具体如下： # ceph -s cluster befd161e-ce9e-427d-9d9b-b683b744645c health HEALTH_ERR 60 pgs are stuck inactive for more than 300 seconds 256 pgs peering 60 pgs stuck inactive monmap e3: 3 mons at {bdc212=192.168.13.212:6789/0,bdc213=192.168.13.213:6789/0,bdc214=192.168.13.214:6789/0} election epoch 48, quorum 0,1,2 bdc212,bdc213,bdc214 osdmap e572: 6 osds: 6 up, 6 in; 92 remapped pgs flags sortbitwise pgmap v378651: 256

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 部署使用ceph集群的时候遇到一个情况，在大规模集群的时候，有节点网络或者osd异常时，mon迟迟不把该异常的osd标down，一直等待900s后mon发现该节点的osd一直没有更新pgmap才把异常的osd标down，并更新osdmap扩散出去。 现象：部署使用ceph集群的时候遇到一个情况，在大规模集群的时候，有节点网络或者osd异常时，mon迟迟不把该异常的osd标down，一直等待900s后mon发现该节点的osd一直没有更新pgmap才把异常的osd标down，并更新osdmap扩散出去。但这个900s内，客户端IO还是会一直往异常的osd上去下发，导致io超时，并进一步影响上次的业务。 原因分析： 我们在mon的日志里面也看到了和异常osd建立心跳的其他osd向mon报告该osd的异常，但mon确实在短时间内没有这些osd标down。查看了一些相关网络和书籍的资料后，才发现了问题。 首先我们关注osd配置中几个相关的配置项： （1）osd_heartbeat_min_peers:10 （2）mon_osd_min_down_reporters:2 （3）mon_osd_min_down_reporters_ratio:0.5 以上参数的之都可以在ceph集群节点上执行ceph daemon osd

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ceph 集群分裂 1 原理 1.1 概述 ceph 集群分裂，本来就是一个违反常理的事情。从ceph的设计原理上就是预防分裂，而且很对分裂有一个专有名词“脑裂”。 什么是脑裂？1个集群分裂为 2个集群叫做脑裂。 预防脑裂的原理：不管是mon，还是osd，服务个数至少>服务个数的一半，也就是经典的>=2n+1 理论。比如： 集群有3个mon服务，活动的mon至少大于等于2个，否则集群不能提供服务。osd也一样，3副本的时候，至少活动的个数超过2副本否则不可用。 1.2 场景 在有些场景中需要ceph集群迁移到其他服务器，但是源服务器上的数据又要保持不变，这就需要对ceph 进行人为分裂，也叫做“欺骗性脑裂” 1.3 原理 例如ceph集群3节点，3 mon，3osd 。ceph-admin ,ceph-node1,ceph-node2. 1 先设置集群数据不迁移使得数据在每个服务器上分布保持稳定 2 节点ceph-node2 停机 3 预备机ceph-test 系统环境，参数，软件 安装设置和ceph-node2一模一样，用来代替原来的ceph-node2 4 新ceph-node2 添加mon 5 ceph-node1 下线 6 删除老ceph-node2 遗留的下线的osd.2 7 新ceph-node2

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ceph的MDS是cephFS文件存储服务的元数据服务。 当创建cephfs后便会有ceph-mds服务进行管理。默认情况下ceph会分配一个mds服务管理cephfs,即使已经创建多个mds服务，如下： [root@ceph-admin my-cluster]# ceph-deploy mds create ceph-node01 ceph-node02 ....... [root@ceph-admin ~]# ceph -s cluster: id: 06dc2b9b-0132-44d2-8a1c-c53d765dca5d health: HEALTH_OK services: mon: 2 daemons, quorum ceph-admin,ceph-node01 mgr: ceph-admin(active) mds: mytest-fs-1/1/1 up {0=ceph-admin=up:active}, 2 up:standby osd: 3 osds: 3 up, 3 in rgw: 2 daemons active data: pools: 8 pools, 64 pgs objects: 299 objects, 137 MiB usage: 3.4 GiB used, 297 GiB /