DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开
DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开

红帽张家驹:基于Ceph的容器存储

近日,以“软件定义存储未来”为题的首届软件定义存储峰会在深圳召开。红帽首席解决方案架构师张家驹做了《基于Ceph的容器存储》的主题分享。张家驹认为,Ceph很大的应用场景是在OpenStack,Ceph伴随着OpenStack一起火了起来。随着容器软件栈的重要性提升,Ceph也逐渐涉猎容器领域。以红帽的角度观察,之前基于面向容器存储的解决方案,今后将会推出Ceph的解决方案。未来,无论是容器还是虚机,基础架构平台会通过Ceph成为整体、统一的软件。

以下为演讲文字整理:

很高兴和大家探讨Ceph的话题,我分享的题目是基于Ceph的容器存储。先来看一下容器的堆栈,Ceph很大的应用场景是在OpenStack,Ceph伴随着OpenStack一起火起来,在传统的存储领域我们逐渐开始使用Ceph。随着容器软件栈的重要性提升,Ceph逐渐也在容器中做一些涉猎。以红帽的角度来讲,之前基于面向容器存储的解决方案,今后会推出基于Ceph的解决方案,面向未来无论是容器还是虚机,基础架构平台会通过Ceph成为整体统一的软件。

在实际的应用场景里,除了容器,虚拟机在很多面向传统应用还是比较多的,在统一的调度层进行Kubernetes实现,存储是由什么实现的?OpenStack的存储一直都是通过Ceph作为底层存储,接下来Ceph也会作为Kubernetes的底层存储给整个平台使用。

去年在北京有一个国外的同事介绍Rook相关的内容,今天我把进展跟大家分享系一下。如果大家不了解Rook,我也会简单介绍一下Rook是什么。Rook是一个控制面,Ceph有很多的问题,我特别注意最后一页的问题,比如说有些跟硬件相关或是跟运维相关,在面向Kubernetes的平台上,在容器出现的时候,最早Docker出现可以简化运维,可以把应用和应用的配置打包放在容器里简化运维。Docker简化运维后来逐渐出现了Kubernetes,容器部署、上线方便。如何管理大规模的平台,Kubernetes逐渐需要持久化的存储,容器是完全的分布式无状态的,实际上我们会发现做到这点太难了,特别是对于复杂的逻辑、传统的应用,没法做到真正的分布式的状态,所以需要持久化的存储。

随着Ceph的成熟会作为统一的存储,我们把它作为容器的软件堆栈,并认为它是完全可以的。把它放在容器里,接下来是如何管理Ceph大规模的集群,我们会看到Rook的架构,这个东西很简单,可以在Ceph项目里找到这个图。

对于Kubernetes来讲,我们认为是控制容器的控制面,如果涉及到存储需要几点,这是Rook目前的发展状态,包括红帽会贡献的内容。现在Rook有一个Operator,Kubernetes上运维不同应用类似机器人角色的新东西,RookOperator针对Ceph和其持久化的存储方案,比如数据库提供Rook的Operator,当然Rook的出现是以Ceph为核心。红帽在Rook里也贡献了很多的代码,我们会用Rook管理在容器软件站里的存储。里面还涉及到Rook Agent,现在用的Rook volume,它作为管理者进行管理运行在每个kubelet的节点,这个节点也会有一个plugin,可以做一些运维相关的工作。

这是简单的图,我们会发现在Ceph运行的每个节点上会有Agent的进程,后面的例子里我们会看到,它是管理里面OSD、Mon,如果不是当前期望的状态,Agent会恢复到期待的状态,对于Kubernetes来讲,它的管理不光是原生的API,实际上扩展到管理Ceph的集群。这是我们对Operator的简单定义,Ceph的集群运行状态不是我们期待的状态,Operator可以恢复到时候我们期望的状态。至于管理哪些方面?目前来说主要是管理Ceph运行的进程,比如说Mon、OSD、RGW、NFS等,还有其他的进程和状态,在Rook里可以管理,对它原生的API进行扩展。

我们要管理Ceph的话,有一些东西是在原生的API里不存在的,需要对它进行扩展。整体的管理框架是前面提到的Operator Framework。之前容器的软件栈更多面向把所有的应用在Kubernetes里走管理,现在更多的精力放在日常管理和运维,当有了Operator以后,它类似于自动化的方式,叫自动化机器人有点夸张,现在的做法是运维人员运行不同的应用,这些不同的应用比如说MYSQL,可能有一些运维的经验,用到什么样的情况需要做怎样的操作,这些已经写在Operator的逻辑里。

Framework是一个框架,负责监控当前的状态,当前的状态如果不是当下希望的会做一些自动的恢复。比如说当前是三个节点,现在宕掉一个节点,现在需要启起来需要运维人员手动启,如果有Operator以后,就会把容器自动启起来,已达到运维的作用。

接下来我们通过具体的例子,介绍如何通过这样的机制做运维?比如说CephCluster是新的类型,可以看到所有Excel都已经容器化,这是它的版本包括使用的网络,这是基本的状态。

接下来再看一个具体的例子,Mon Settings,集群里要求是三个,这里指定是3,还有一些其他的属性,如果我们通过这个方式把Mon起来,现在手动杀掉一个Mon,因为有了Operator,有了Rook的Operator,会自动把集群的Mon恢复成三个,有一些人为的工作可以通过这种Operator方式实现。

对OSD的配置,Rook还是属于早期的发展阶段,一开始安装部署Ceph的集群,选取节点的时候用怎样的方式?是用机器上所有节点的所有盘还是一些有选择的?这个例子是所有的节点、所有的盘,里面指定节点上的盘,实际上都是在右边指定的,里面哪些存储设备。或是一些规则,比如说我们是用里面的正确表达式。我们对于一些性能上的考量,比如说放在SSD上,对于DB放在什么上,不同的配置、设置都可以在里面体现。

比如说配置RBD Mirroring,包括RGW,RGW的几个池子,包括副本池,在整个配置里都可以指定,包括配置Ceph的文件系统,Ceph文件系统我们认为也是逐渐走向成熟的状态,我们认为给容器的软件是完全没有问题的。

最后讲一下RookAgent以及未来的Rook发展趋势,简单说基于Ceph的容器存储我们目前通过Rook的方式,把Ceph给到容器的软件堆站用,有Rook和没Rook的好处,之前大部分的工作还是需要手动做,Kubernetes平台很多的应用管理完全通过平台自身的机制就可以完成,比如说上面部署MYSQL,有MYSQL的Operator,对于Ceph也是一个集群,如何更好的管理好集群?我们是需要工具的。现在可以做的是,比如说第一步的安装、部署、配置以及简单的进程数,我们有三个进程,哪个坏掉会重启。未来很多的运维工作都可以通过Ceph、Rook本身做。比如说我们如何发现盘坏了,如果盘坏了需要换盘、敲几个命令把盘摘掉加上去。还有一些工作比较复杂一点,Ceph现在很多运维监控是通过外围做的,现在我们可以搜集很多的信息,也可以挂一些普罗米修斯做整体的监控、展现。这些东西都是可以跟Operator本身结合起来,通过监控可以发现一些信息,如果有什么动作、启发式的可以通过Operator在集群里做一些动作,比如说识别一些亚健康的状态。一旦做了,比如说剔掉一个OSD、添加一个OSD,类似这样的工作我们可以通过取得信息,通过这些信息把前后两个工作勾起来。

还有一点是Rook在未来一定要改变,红帽正在做,不久就会发布,目前它的机制还是FlexVolume,未来可能是从事CSI的标准,这块通过CSI管理Ceph的存储,今天我的演讲就到这里,谢谢大家。

未经允许不得转载:DOIT » 红帽张家驹:基于Ceph的容器存储