Ceph Luminous 安装要点

只记录Luminous 和旧版有区别的地方,基本流程没有变,参见旧文。 Bootstrap keyring 之前的版本在初始化mon的时候会在/var/lib/ceph/bootstrap-{节点名}/自动生成bootstrap其他节点用的keyring,但是有时候又不会。 如果没有这个keyring,可以手动生成以初始化除了mon以外的节点。 根据文档: ceph-authtool --create-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring \ --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' 但是不知道为什么并没有用,在ceph auth list里面并没有看到新的key生成。所以还是用老方法: ceph auth get-or-create client.bootstrap-osd mon 'profile bootstrap-osd' 创建bluestore Luminous 默认存储backend 由filestore替换成了新的bluestore,同时也简化了初始化流程: ceph-volume lvm create --data {data-path} 要求硬盘没有挂载。 这样默认创建出来的bluestore 会分出两个区,一个区给block,一个区给db。如果有更好的设备,可以按如下方式把db单独放在另一块盘。 假设sdc是一块ssd,想要把所有bluestore的db都放在sdc上。在sdc上创建bluestore rocksdb用的lg: pvcreate /dev/sdc vgcreate ceph-journal /dev/sdc 对每个OSD, - 创建db用的lv: lvcreate --size 10G ceph-journal --name ${dev}.db && \ lvcreate --size 10G ceph-journal --name ${dev}.wal prepare, activate: ceph-volume lvm prepare --data /dev/${dev} --block.
Read more...

Ceph手动升级要点

总结一下自己从Hammer手动(不使用ceph-deploy)升级到Jewel遇到的问题作为前车之鉴。重要信息没有列举,没有直接遇到这些问题的读者请读完后再实施。 0. 安装问题 先升级Ceph,这一步没有什么,因为升级并不会重启现有节点,所以还是旧的在跑,需要注意的都在重启的时候。之前是用自己的源安装的,这次用外部源,国内最好配置国内源,一个示例可用的完整的使用了阿里的Ceph源的repo如下,写入/etc/yum.repos.d/ceph.repo即可。 [ceph] name=Ceph packages for $basearch baseurl=http://mirrors.aliyun.com/ceph/rpm-jewel/el7/$basearch enabled=1 priority=2 gpgcheck=1 [ceph-noarch] name=Ceph noarch packages baseurl=http://mirrors.aliyun.com/ceph/rpm-jewel/el7/noarch enabled=1 priority=2 gpgcheck=1 [ceph-source] name=Ceph source packages baseurl=https://mirrors.aliyun.com/ceph/rpm-jewel/el7/SRPMS enabled=0 priority=2 gpgcheck=1 一开始使用这个源配置的时候遇到Public key for *.rpm is not installed错误,gpgcheck改成0即可。 然后直接yum upgrade ceph。可能会遇到依赖不满足的问题,可以试下安装epel的源:epel-release。 接下来注意一下重启的步骤,不然可能会出问题: 1. MON 2. OSD 3. MDS 4. RGW 1. 重启 Jewel版Ceph的默认用户变成ceph:ceph,然而低版本的则默认是root,直接重启会造成/var/lib/ceph/{node-type} permission denied问题。 需要将/var/lib/ceph以及子目录赋给ceph:ceph:chown -R ceph:ceph /var/lib/ceph。但是chown并不管链接,OSD的journal和data都是链接过来的,所以还需要chown data和journal。 Jewel与Hammer不同,使用systemctl作为服务管理,不再使用/etc/init.d/ceph了,这里说下升级会用到的systemctl用法给不熟悉的读者。systemctl是支持通配符的,操作所有ceph服务: systemctl {status, start, stop} ceph-*,注意不要少了-。重启前的旧进程因为是init script启动的,所以在systemctl下显示的是ceph-{node-type}.{instance-id}.***的形式,可以先status,看到名字之后再复制、stop,最简便的办法是systemctl stop ceph-{node-type}*,之后启动就是正常的systemctl service的命名方式了:systemctl start ceph-{node-type}@{instance-id}.
Read more...

Ceph手动部署要点

虽然现在preferred的安装方式是采用ceph-deploy,简化了安装了流程,而且便于日后的维护升级。但是手动走一遍有利于新手理解一些Ceph的概念。这篇文章总结一下我几次手动部署的步骤,特别注意了一下官方文档中不清楚了错误的地方。 (针对10.2.x Jewel,12.2.x Luminous 参见Ceph Luminous 安装要点) 0. 安装 至少在Hammer版,Ceph的rpm少包含了一个重要的依赖,在CentOS上导致使用init script的时候会报: /etc/init.d/ceph: line 15: /lib/lsb/init-functions: No such file or directory 需要安装redhat-lsb,只有这个坑,其他的直接yum或者自己构建即可。 需要提醒的是,国内使用官方yum源可能很慢,可以使用国内的镜像源,例如阿里或网易。 1. Bootstrap monitors 首先要初始化monitors,这是最复杂的步骤,有了mon集群之后,其他集群就可以很方便地加入mon管理的节点拓扑了。 1.1 需要的东西 fsid: uuidgen cluster name monitor name: hostname -s,注意,下面所提及的命令中的hostname,都是执行命令的机器的短hostname,即hostname -s,所以为了区分节点,建议使用FQDN,比如node1.cluster1.ceph,这样该机的短hostname即为node1 monitor map:monmaptool mointor keyring:monitor之间使用密钥通信,初始化mon时需要使用密钥生成的keyring administrator keyring:创建管理用户client.admin 1.2 具体步骤 创建第一个节点,后面的节点因为在这个节点中已经生成了相关文件,会省略一些步骤。 创建/etc/ceph/{cluster name}.conf,最小模板: [global] fsid = {fsid} mon initial members = {hostname}[,{hostname}] mon host = {ip}[,{ip}] 创建 mon keyring: ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon.
Read more...

FastDFS与Ceph的比较

研究分布式存储只看Ceph是不够的,想有个横向对比,看看各有什么优缺点,从而深入对Ceph和分布式存储的理解。我司图片存储使用的是FastDFS,所以从它看起。 因为没有真正使用过,只是为了了解概念,所以浅尝辄止,参考资料比较单一,可能存在误解,里面甚至有我的很多猜测、思考和问题,请想了解FastDFS的同学绕道。 本质差别 FastDFS和Ceph的本质区别:FastDFS不是一个对象存储,是个分布式的文件存储,虽然和传统的NAS有差别,但其本质还是文件存储。所以这个对比其实不是那么横向,差别太大了: FastDFS以文件为单位,Ceph以Object为存储单位 FastDFS没有strip文件,而Ceph(fs)把文件分成object分布在OSD中,read时可以并发,FastDFS没有这样的功能,性能受限于单机 FastDFS节点 FastDFS的节点有两种:tracker和storage。 Tracker节点负责协调集群运作,storage上报心跳、记录storage所属group等,角色有点类似于Ceph中的MON。这些信息很少,且都可以通过storage上报获得无需持久化,所以都存储在内存中,也使得tracker的集群佷容易扩展,每个tracker是平等的。 这里我有一个疑问,既然是平等的,如何保障一致性?是几个节点同步的,还是storage上报时要多写? 我的猜测是靠同步的,因为下面介绍了写流程之后,你会发现其实一致性并不是很重要。一会儿我们再回到这个问题。 Storage就是存储节点了。 Storage以group为单位,一个group内的storage互为备份。每个storage可以挂不同的盘到不同的*path*。 这种备份是简单的镜像,所以一个group的总容量是最低的那个server决定的,没有Ceph CRUSH map的自动依据硬盘大小的weight功能。 文件上传后以hash为依据分布在storage的文件夹中。 FastDFS上传过程 上传文件时,tracker会选择一个group,可以配置以下方式: - RR,轮询 - Specified,指定一个group - Load balance,剩余空间多的优先 选定group之后选择一个storage。规则是: RR Order by IP Order by priority,优先级排序 问题:既然group内的storage是镜像的,为什么还要选择一个上传呢,随机一个不都可以吗? 然后选定path,也就是同一台storage上不同的数据盘: RR 剩余空间多优先 Storage生成fileid:base64({storage IP}{create time}{file size}{file crc32}{random number})。 接着选定两级子目录,这个不重要且很简单,只是为了避免同个目录下的文件过多。 生成文件名,包含: - group - 目录 - 两级子目录 - fileid - 文件后缀(客户端指定,区分类型) 一个文件名的例子:group1/M00/00/0C/wKjRbExx2K0AAAAAAAANiSQUgyg37275.h。 FastDFS文件同步 文件写入上文规则选出的一个storage server即返回成功,再由后台线程同步到其他节点。而Ceph的要求是写入主primary OSD之后所有副本比如第二第三OSD完成之后才返回成功,数据安全性更高。 只primary写完就返回,那其它同group的storage什么时候能提供服务?这个要靠是否同步完成来判断。同步的进度靠primary storage的binlog记录,binlog会同步到tracker,读请求时tracker根据同步进度选择可读的storage。
Read more...