原文链接:https://www.qikqiak.com/k8strain/storage/ceph/#_11
Ceph 是一个统一的分布式存储系统,提供较好的性能、可靠性和可扩展性。
1、Object:有原生 API,而且也兼容 Swift 和 S3 的 API
2、Block:支持精简配置、快照、克隆
3、File:Posix 接口,支持快照
Monitor:一个 Ceph 集群需要多个 Monitor 组成的小集群,它们通过 Paxos 同步数据,用来保存 OSD 的元数据。
OSD:全称 Object Storage Device
,也就是负责响应客户端请求返回具体数据的进程,一个 Ceph 集群一般都有很多个 OSD。主要功能用于数据的存储,当直接使用硬盘作为存储目标时,一块硬盘称之为 OSD
,当使用一个目录作为存储目标的时候,这个目录也被称为 OSD
。
MDS:全称 Ceph Metadata Server
,是 CephFS 服务依赖的元数据服务,对象存储和块设备存储不需要该服务。
Object:Ceph 最底层的存储单元是 Object 对象,一条数据、一个配置都是一个对象,每个 Object 包含 ID、元数据和原始数据。
Pool:Pool 是一个存储对象的逻辑分区,它通常规定了数据冗余的类型与副本数,默认为3副本。对于不同类型的存储,需要单独的 Pool,如 RBD。
PG:全称 Placement Grouops
,是一个逻辑概念,一个 OSD 包含多个 PG。引入 PG 这一层其实是为了更好的分配数据和定位数据。每个 Pool
内包含很多个 PG,它是一个对象的集合,服务端数据均衡和恢复的最小单位就是 PG。
pool 是 ceph 存储数据时的逻辑分区,它起到 namespace 的作用
每个 pool 包含一定数量(可配置)的 PG
PG 里的对象被映射到不同的 Object 上
pool 是分布到整个集群的
FileStore与BlueStore:FileStore 是老版本默认使用的后端存储引擎,如果使用 FileStore,建议使用 xfs
文件系统。BlueStore 是一个新的后端存储引擎,可以直接管理裸硬盘,抛弃了 ext4 与 xfs 等本地文件系统。可以直接对物理硬盘进行操作,同时效率也高出很多。
RADOS:全称 Reliable Autonomic Distributed Object Store
,是 Ceph 集群的精华,用于实现数据分配、Failover 等集群操作。
Librados:Librados
是 Rados 提供库,因为 RADOS 是协议很难直接访问,因此上层的 RBD、RGW 和 CephFS 都是通过 librados 访问的,目前提供 PHP、Ruby、Java、Python、C 和 C++ 支持。
CRUSH:CRUSH
是 Ceph 使用的数据分布算法,类似一致性哈希,让数据分配到预期的地方。
RBD:全称 RADOS Block Device
,是 Ceph 对外提供的块设备服务,如虚拟机硬盘,支持快照功能。
RGW:全称是 RADOS Gateway
,是 Ceph 对外提供的对象存储服务,接口与 S3 和 Swift 兼容。
CephFS:全称 Ceph File System
,是 Ceph 对外提供的文件系统服务。
典型设备:
磁盘阵列,硬盘,主要是将裸磁盘空间映射给主机使用的。
优点:
1、通过 Raid 与 LVM 等手段,对数据提供了保护。
2、多块廉价的硬盘组合起来,提高容量。
3、多块磁盘组合出来的逻辑盘,提升读写效率。
缺点:
1、采用 SAN 架构组网时,光纤交换机,造价成本高。
2、主机之间无法共享数据。
使用场景
1、Docker 容器、虚拟机磁盘存储分配。
2、日志存储
3、文件存储
典型设备
FTP、NFS 服务器,为了克服块存储文件无法共享的问题,所以有了文件存储,在服务器上架设 FTP 与 NFS 服务器,就是文件存储。
优点:
1、造价低,随便一台机器就可以了
2、方便文件可以共享
缺点:
1、读写速率低
2、传输速率慢
使用场景
1、日志存储
2、有目录结构的文件存储
典型设备
内置大容量硬盘的分布式服务器(swift, s3);多台服务器内置大容量硬盘,安装上对象存储管理软件,对外提供读写访问功能。
优点:
1、具备块存储的读写高速。
2、具备文件存储的共享等特性
使用场景:(适合更新变动较少的数据)
1、图片存储
2、视频存储
由于我们这里在 Kubernetes 集群中使用,也为了方便管理,我们这里使用 Rook 来部署 Ceph 集群,Rook 是一个开源的云原生存储编排工具,提供平台、框架和对各种存储解决方案的支持,以和云原生环境进行本地集成。
Rook 将存储软件转变成自我管理、自我扩展和自我修复的存储服务,通过自动化部署、启动、配置、供应、扩展、升级、迁移、灾难恢复、监控和资源管理来实现。Rook 底层使用云原生容器管理、调度和编排平台提供的能力来提供这些功能,其实就是我们平常说的 Operator。Rook 利用扩展功能将其深度集成到云原生环境中,并为调度、生命周期管理、资源管理、安全性、监控等提供了无缝的体验。有关 Rook 当前支持的存储解决方案的状态的更多详细信息,可以参考 Rook 仓库 的项目介绍。
组件
1、Rook Operator:Rook 的核心组件,Rook Operator 是一个简单的容器,自动启动存储集群,并监控存储守护进程,来确保存储集群的健康。
2、Rook Agent:在每个存储节点上运行,并配置一个 FlexVolume 或者 CSI 插件,和 Kubernetes 的存储卷控制框架进行集成。Agent 处理所有的存储操作,例如挂接网络存储设备、在主机上加载存储卷以及格式化文件系统等。
3、Rook Discovers:检测挂接到存储节点上的存储设备。
Rook 还会用 Kubernetes Pod 的形式,部署 Ceph 的 MON、OSD 以及 MGR 守护进程。Rook Operator 让用户可以通过 CRD 来创建和管理存储集群。每种资源都定义了自己的 CRD:
1、RookCluster:提供了对存储机群的配置能力,用来提供块存储、对象存储以及共享文件系统。每个集群都有多个 Pool。
2、Pool:为块存储提供支持,Pool 也是给文件和对象存储提供内部支持。
3、Object Store:用 S3 兼容接口开放存储服务。
4、File System:为多个 Kubernetes Pod 提供共享存储。
首先在节点上安装lvm2
软件包:
# Centos sudo yum install -y lvm2 # Ubuntu sudo apt-get install -y lvm2
这里部署用的是 release-1.2 版本的 Rook,部署清单文件地址:https://github.com/rook/rook/tree/release-1.2/cluster/examples/kubernetes/ceph。
从上面链接中获取 common.yaml 与 operator.yaml 两个资源清单文件:
# 会安装crd、rbac相关资源对象 $ kubectl apply -f common.yaml # 安装 rook operator $ kubectl apply -f operator.yaml
在继续操作之前,验证 rook-ceph-operator
是否处于“Running”
状态:
$ kubectl get pod -n rook-ceph NAME READY STATUS RESTARTS AGE rook-ceph-operator-658dfb6cc4-qx9bg 1/1 Running 0 69s rook-discover-t8xqd 1/1 Running 0 13s rook-discover-xxwf6 1/1 Running 0 13s
可以看到 Operator 运行成功后,还会有一个 DaemonSet 控制器运行得 rook-discover 应用,当 Rook Operator
处于 Running 状态,我们就可以创建 Ceph 集群了。为了使集群在重启后不受影响,请确保设置的 dataDirHostPath
属性值为有效得主机路径。更多相关设置,可以查看集群配置相关文档。
创建如下资源清单:
apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name: rook-ceph namespace: rook-ceph spec: cephVersion: # 最新得 ceph 镜像, 可以查看 https://hub.docker.com/r/ceph/ceph/tags image: ceph/ceph:v14.2.5 dataDirHostPath: /var/lib/rook # 主机有效目录 mon: count: 2 dashboard: enabled: true storage: useAllNodes: true useAllDevices: false # 重要: Directories 应该只在预生产环境中使用 directories: - path: /data/rook
其中有几个比较重要的字段:
dataDirHostPath
:宿主机上的目录,用于每个服务存储配置和数据。如果目录不存在,会自动创建该目录。由于此目录在主机上保留,因此在删除 Pod 后将保留该目录,另外不得使用以下路径及其任何子路径:/etc/ceph
、/rook
或 /var/log/ceph
。useAllNodes
:用于表示是否使用集群中的所有节点进行存储,如果在 nodes
字段下指定了各个节点,则必须将useAllNodes
设置为 false。useAllDevices
:表示 OSD 是否自动使用节点上的所有设备,一般设置为 false,这样可控性较高directories
:一般来说应该使用一块裸盘来做存储,有时为了测试方便,使用一个目录也是可以的,当然生成环境不推荐使用目录。除了上面这些字段属性之外还有很多其他可以细粒度控制得参数,可以查看集群配置相关文档。
现在直接创建上面的 CephCluster
对象即可,创建完成后,Rook Operator就会根据我们的描述信息去自动创建Ceph集群了。
要验证集群是否处于正常状态,我们可以使用 Rook 工具箱 来运行 ceph status
命令查看。
Rook 工具箱是一个用于调试和测试 Rook 的常用工具容器,该工具基于 CentOS 镜像,所以可以使用 yum 来轻松安装更多的工具包。我们这里用 Deployment 控制器来部署 Rook 工具箱,部署的资源清单文件如下所示:
apiVersion: apps/v1 kind: Deployment metadata: name: rook-ceph-tools namespace: rook-ceph labels: app: rook-ceph-tools spec: replicas: 1 selector: matchLabels: app: rook-ceph-tools template: metadata: labels: app: rook-ceph-tools spec: dnsPolicy: ClusterFirstWithHostNet containers: - name: rook-ceph-tools image: rook/ceph:v1.2.1 command: ["/tini"] args: ["-g", "--", "/usr/local/bin/toolbox.sh"] imagePullPolicy: IfNotPresent env: - name: ROOK_ADMIN_SECRET valueFrom: secretKeyRef: name: rook-ceph-mon key: admin-secret securityContext: privileged: true volumeMounts: - mountPath: /dev name: dev - mountPath: /sys/bus name: sysbus - mountPath: /lib/modules name: libmodules - name: mon-endpoint-volume mountPath: /etc/rook # 如果设置 hostNetwork: false, "rbd map" 命令会被 hang 住, 参考 https://github.com/rook/rook/issues/2021 hostNetwork: true volumes: - name: dev hostPath: path: /dev - name: sysbus hostPath: path: /sys/bus - name: libmodules hostPath: path: /lib/modules - name: mon-endpoint-volume configMap: name: rook-ceph-mon-endpoints items: - key: data path: mon-endpoints
一旦 toolbox 的 Pod 运行成功后,我们就可以使用下面的命令进入到工具箱内部进行操作:
$ kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash
工具箱中的所有可用工具命令均已准备就绪,可满足您的故障排除需求。例如:
ceph status ceph osd status ceph df rados df
比如现在我们要查看集群的状态,需要满足下面的条件才认为是健康的:
1、所有 mons 应该达到法定数量
2、mgr 应该是激活状态
3、至少有一个 OSD 处于激活状态
4、如果不是 HEALTH_OK 状态,则应该查看告警或者错误信息
# ceph status cluster: id: 01afabec-6f13-4336-a2cb-c91bbbca7798 health: HEALTH_WARN OSD count 2 < osd_pool_default_size 3 services: mon: 2 daemons, quorum a,b (age 3m) mgr: a(active, since 2m) osd: 2 osds: 2 up (since 2m), 2 in (since 2m) data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 45 GiB used, 25 GiB / 70 GiB avail pgs:
如果群集运行不正常,可以查看 Ceph 常见问题以了解更多详细信息和可能的解决方案。
Ceph 有一个 Dashboard 工具,我们可以在上面查看集群的状态,包括总体运行状态,mgr、osd 和其他 Ceph 进程的状态,查看池和 PG 状态,以及显示守护进程的日志等等。
我们可以在上面的 cluster CRD 对象中开启 dashboard,设置dashboard.enable=true
即可,这样 Rook Operator 就会启用 ceph-mgr dashboard 模块,并将创建一个 Kubernetes Service 来暴露该服务,将启用端口 7000 进行 https 访问,如果 Ceph 集群部署成功了,我们可以使用下面的命令来查看 Dashboard 的 Service:
$ kubectl get svc -n rook-ceph NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE csi-cephfsplugin-metrics ClusterIP 10.99.162.98 <none> 8080/TCP,8081/TCP 5m47s csi-rbdplugin-metrics ClusterIP 10.103.124.243 <none> 8080/TCP,8081/TCP 5m47s rook-ceph-mgr ClusterIP 10.102.96.161 <none> 9283/TCP 4m33s rook-ceph-mgr-dashboard ClusterIP 10.98.21.237 <none> 7000/TCP 4m58s rook-ceph-mon-a ClusterIP 10.99.73.73 <none> 6789/TCP,3300/TCP 5m20s rook-ceph-mon-b ClusterIP 10.108.132.47 <none> 6789/TCP,3300/TCP 5m15s
这里的 rook-ceph-mgr 服务用于报告 Prometheus metrics 指标数据的,而后面的的 rook-ceph-mgr-dashboard 服务就是我们的 Dashboard 服务,如果在集群内部我们可以通过 DNS 名称 http://rook-ceph-mgr-dashboard.rook-ceph:7000
或者 CluterIP http://10.111.195.180:7000
来进行访问,但是如果要在集群外部进行访问的话,我们就需要通过 Ingress 或者 NodePort 类型的 Service 来暴露了,为了方便测试我们这里创建一个新的 NodePort 类型的服务来访问 Dashboard,资源清单如下所示:
apiVersion: v1 kind: Service metadata: name: rook-ceph-mgr-dashboard-external namespace: rook-ceph labels: app: rook-ceph-mgr rook_cluster: rook-ceph spec: ports: - name: dashboard port: 7000 protocol: TCP targetPort: 7000 selector: app: rook-ceph-mgr rook_cluster: rook-ceph type: NodePort
创建完成后我们可以查看到新创建的 rook-ceph-mgr-dashboard-external 这个 Service 服务:
$ kubectl get svc -n rook-ceph NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE csi-cephfsplugin-metrics ClusterIP 10.99.162.98 <none> 8080/TCP,8081/TCP 9m17s csi-rbdplugin-metrics ClusterIP 10.103.124.243 <none> 8080/TCP,8081/TCP 9m17s rook-ceph-mgr ClusterIP 10.102.96.161 <none> 9283/TCP 8m3s rook-ceph-mgr-dashboard ClusterIP 10.98.21.237 <none> 7000/TCP 8m28s rook-ceph-mgr-dashboard-external NodePort 10.110.93.143 <none> 7000:32745/TCP 7s rook-ceph-mon-a ClusterIP 10.99.73.73 <none> 6789/TCP,3300/TCP 8m50s rook-ceph-mon-b ClusterIP 10.108.132.47 <none> 6789/TCP,3300/TCP 8m45s
现在我们需要通过 http://<NodeIp>:32745
就可以访问到 Dashboard 了。
但是在访问的时候需要我们登录才能够访问,Rook 创建了一个默认的用户 admin,并在运行 Rook 的命名空间中生成了一个名为 rook-ceph-dashboard-admin-password
的 Secret,要获取密码,可以运行以下命令:
$ kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo xxxx(登录密码)
现在我们的 Ceph 集群搭建成功了,我们就可以来使用存储了。首先我们需要创建存储池,可以用 CRD 来定义 Pool。Rook 提供了两种机制来维持 OSD:
1、副本:缺省选项,每个对象都会根据 spec.replicated.size
在多个磁盘上进行复制。建议非生产环境至少 2 个副本,生产环境至少 3 个。
2、Erasure Code:是一种较为节约的方式。EC 把数据拆分 n 段(spec.erasureCoded.dataChunks
),再加入 k 个代码段(spec.erasureCoded.codingChunks
),用分布的方式把 n+k
段数据保存在磁盘上。这种情况下 Ceph 能够隔离 k 个 OSD 的损失。
我们这里使用副本的方式,创建如下所示的 RBD 类型的存储池:
apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata: name: k8s-test-pool # operator会监听并创建一个pool,执行完后界面上也能看到对应的pool namespace: rook-ceph spec: failureDomain: host # 数据块的故障域: 值为host时,每个数据块将放置在不同的主机上;值为osd时,每个数据块将放置在不同的osd上 replicated: size: 3 # 池中数据的副本数,1就是不保存任何副本
存储池创建完成后我们在 Dashboard 上面的确可以看到新增了一个 pool,而且集群健康状态下多了一条日志:
Health check update: too few PGs per OSD (6 < min 30) (TOO_FEW_PGS)
这是因为每个 osd 上的 pg 数量小于最小的数目30个。pgs 为8,因为是3副本的配置,所以当有4个 osd 的时候,每个 osd 上均分了8/4 *3=6个pgs,也就是出现了如上的错误小于最小配置30个,集群这种状态如果进行数据的存储和操作,集群会卡死,无法响应io,同时会导致大面积的 osd down。
我们可以进入 toolbox 的容器中查看上面存储的 pg 数量,并可以通过增加pg_num来解决这个问题:
$ ceph osd pool get k8s-test-pool pg_num pg_num: 8 $ ceph osd pool set k8s-test-pool pg_num 64 set pool 1 pg_num to 64 $ ceph -s cluster: id: 01afabec-6f13-4336-a2cb-c91bbbca7798 health: HEALTH_WARN OSD count 2 < osd_pool_default_size 3 services: mon: 2 daemons, quorum a,b (age 18m) mgr: a(active, since 17m) osd: 2 osds: 2 up (since 16m), 2 in (since 16m) data: pools: 1 pools, 64 pgs objects: 0 objects, 0 B usage: 45 GiB used, 25 GiB / 70 GiB avail pgs: 64 active+undersized
不过需要注意的是我们这里的 pool 上没有数据,所以修改 pg 影响并不大,但是如果是生产环境重新修改 pg 数,会对生产环境产生较大影响。因为 pg 数变了,就会导致整个集群的数据重新均衡和迁移,数据越大响应 io 的时间会越长。所以,最好在一开始就设置好 pg 数。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-ceph-block provisioner: rook-ceph.rbd.csi.ceph.com parameters: # clusterID 是 rook 集群运行的命名空间 clusterID: rook-ceph # 指定存储池 pool: k8s-test-pool # RBD image (实际的存储介质) 格式. 默认为 "2". imageFormat: "2" # RBD image 特性. CSI RBD 现在只支持 `layering` . imageFeatures: layering # Ceph 管理员认证信息,这些都是在 clusterID 命名空间下面自动生成的 csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph # 指定 volume 的文件系统格式,如果不指定, csi-provisioner 会默认设置为 `ext4` csi.storage.k8s.io/fstype: ext4 # uncomment the following to use rbd-nbd as mounter on supported nodes # **IMPORTANT**: If you are using rbd-nbd as the mounter, during upgrade you will be hit a ceph-csi # issue that causes the mount to be disconnected. You will need to follow special upgrade steps # to restart your application pods. Therefore, this option is not recommended. #mounter: rbd-nbd reclaimPolicy: Delete
直接创建上面的StorageClass资源对象,接着创建一个PVC来使用这个StorageClass对象:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claim labels: app: wordpress spec: storageClassName: rook-ceph-block accessModes: - ReadWriteOnce resources: requests: storage: 20Gi
创建完成后我们可以看到我们的 PVC 对象已经是 Bound 状态了,自动创建了对应的 PV,然后我们就可以直接使用这个 PVC 对象来做数据持久化操作了。
$ kubectl get pvc -l app=wordpress NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE mysql-pv-claim Bound pvc-865bff43-d921-491b-9452-aeae64e80109 20Gi RWO rook-ceph-block 16s
在官方仓库 cluster/examples/kubernetes 目录下,官方给了个 wordpress 的例子,可以直接运行测试即可:
$ kubectl apply -f mysql.yaml $ kubectl apply -f wordpress.yaml
官方的这个示例里面的 wordpress 用的 Loadbalancer 类型,我们可以改成 NodePort:
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 54m wordpress NodePort 10.104.129.67 <none> 80:32383/TCP 51s wordpress-mysql ClusterIP None <none> 3306/TCP 63s
当应用都处于 Running 状态后,我们可以通过 `http://<任意节点IP>:32383 去访问 wordpress 应用:
现在我在WordPress里创建了一个Ceph测试文章。
现在将应用的Pod全部删掉重建:
$ kubectl delete pod -l app=wordpress pod "wordpress-7bfc545758-pgzth" deleted pod "wordpress-mysql-764fc64f97-vm6ml" deleted $ kubectl get pod -l app=wordpress NAME READY STATUS RESTARTS AGE wordpress-7bfc545758-chffm 1/1 Running 0 41s wordpress-mysql-764fc64f97-k5phc 1/1 Running 0 41s
当 Pod 重建完成后再次访问 wordpress 应用的主页我们可以发现之前我们添加的数据仍然存在,这就证明我们的数据持久化是正确的。