近日，以“软件定义存储未来”为题的首届软件定义存储峰会在深圳召开。红帽首席解决方案架构师张家驹做了《基于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的存储，今天我的演讲就到这里，谢谢大家。
