云计算|OpenStack|Cinder道术

Posted 2021-04-24 未名小宇宙

不是只有AI才是主流，云计算正在大行其道

有这么一群人，每天公交、地铁、单车、11路，风雨无阻，一起走向春天里，即使在车里哭完，也要笑着走进办公室，即使夜已深，依旧穿梭在归家的路上。这是理想、是工作、还是生活？其实，这是80、90后的青春，时代正在因你们而改变。

图1 宁静夜晚

为何要写本文？很多OpenStack技术文章，要么简单地说工作原理，要么介绍安装配置，要么分析源代码，没有系统性地分析架构和工作原理，导致很多初学者学习遇到困难，经常出现只会机械操作、不懂工作原理、阅读代码也不知道啥意义、一直无法入门。通过深入浅出OpenStack的架构和工作原理，帮助大家快速入门。本文先分析Cinder，其余组件分析将陆续更新。

一、OpenStack家喻户晓：OpenStack已经成为云计算（IaaS）事实标准，广泛应用在公有云、行业云、私有云、混合云等场景，融合了上下游关系，形成了云计算商业生态。也许个别公有云采用了自己的技术，但私有云采用OpenStack是一种趋势，即使是公有云大咖也不例外，他们输出私有云时，OpenStack也是必然的选择，因为用户只认可OpenStack，且可控、且安全、还可以定制开发。

OpenStack重要吗？云计算浪潮正在向传统行业渗透，市场空间非常广阔，而OpenStack作为云计算的准标配，其很重要程度是毋庸置疑的。

OpenStack难学吗？OpenStack拥有数百个组件，千万行源代码，是个庞大复杂的系统工程。好在OpenStack架构清晰且灵活，社区文档丰富，你可以先在某一个方向深耕，比如计算、存储、网络，熟悉之后再扩散到其他方向。

如何OpenStack大咖呢？首先，需要有天赋；其次，需要有经验，懂业务、懂原理、懂开发、懂运维；最后，需要向社区贡献代码，回馈社区，提升你在国际上的知名度。

 图2 OpenStack大杂烩

二、Cinder啥东东：Cinder是OpenStack的卷存储管理组件，提供卷的CRUD操作（卷又是啥：你理解为操作系统的一块磁盘分区就行），创建出来的卷可以供Nova（虚拟机或裸机CRUD操作）挂载到虚拟机或裸机里，存放操作系统根文件、数据文件、日志文件等，也可以供Glance（镜像CRUD操作）存放镜像文件。Cinder是控制层面，通过调用后端存储（例如：EMC、NetApp）的管理接口，实现卷的CRUD操作，走的是控制流。虚拟机或裸机与后端存储之间是传输数据，走的是数据流。因为控制流对性能实时性要求不高，这也就是为什么控制层面Cinder可以用动态解释性语言Python实现，而数据层面Ceph采用静态编译语言C/C++实现。

三、Cinder商业生态：Cinder控制卷的CRUD操作，而卷是由各种存储厂商（例如，EMC、NetApp等）的存储设备提供，Cinder通过插件集成了各种存储厂商的存储driver（这里仅仅是控制层面driver，不是传统意义上的数据层面driver）和光纤交换机厂商的FC driver，将各个存储厂商融合在一起。随着云计算的推广，传统存储市场在萎缩，各大存储厂商基本都在积极贡献driver，想借助Cinder推广销售其存储产品，这是基本的求生之道（小插曲：EMC被Dell收购，Cisco拟收购NetApp，Pure寻求出售，独立的存储公司将难以生存）。因为社区PTL和Core Reviewer决定了Cinder的走向，所以PTL和Core Reviewer是各大厂商的必争之地，确保自己用于话语权。

图3 Cinder drivers

Cinder除了整合了存储厂商，还整合了user、contributor（提交Patch，整理文档）、developer（提交Patch，不提交Patch）、商业培训认证等。

四、Cinder架构之道：

图4 Cinder架构

Cinder由四部分组成：API、Scheduler、Volume、Backup（略）。

Cinder API（API网关）：OpenStack组件朝着微服务方向发展，组件之间（例如，Nova、Cinder、Neutron）采用RestFul API相互通信，达到解耦目的，同一组件内部的不同模块（例如Cinder API、Scheduler、Volume）之间采用轻量级MQ（例如，RabbitMQ）相互通信，提高通信效率。Cinder API启动一个WSGI服务，监听8776端口，User（可能是CinderClient，也可能是Horizon Portal，还可能是你定制的其他程序）通过用户名和密码去Keystone中获取token，把token放到请求头中一起发送给Cinder API服务，Cinder API接收来自User的RestFul请求后，去Keystone检查token是否合法，且检查是否满足/etc/policy.json中定义操作权限，请求合法且满足满足权限，通过RabbitMQ把请求分发给目标Cinder Scheduler服务或Cinder Volume服务，进行后续动作。Cinder API有两种版本号：一是主版本号（major versions），在请求URL中指定；二是微版本号（micro versions），在请求header里指定X-OpenStack-Cinder-API-Version，主要是新增一个小功能，只有在特定微版本里才生效；版本号检查也是Cinder API负责的。

Cinder Scheduler（调度器）：Cinder Scheduler收到创卷请求后，首先通过Filters进行过滤，从诸多的Cinder Volume中选择满足要求的Cinder Volume，可能是多个，再通过Weighter进行过滤，从满足要求的Cinder Volume中选择唯一的Cinder Volume，然后通过RabbitMQ通知唯一Cinder Volume去创卷。Filter和Weighter都是插件方式开启和停止，也可以根据实际需要定制自己的Filter和Weighter，满足特定需求。

常见Filter列表（你也可以定制自己的Filter）：

Filter是顺序执行的，前面的Filter没有满足要求，直接pass掉，不会执行后面Filter。

图5 Cinder Filters

常见Weighter列表（你也可以定制自己的Weighter）：

Weighter也是顺序执行的，计算每一个Weighter的值，进行归一化，把所有的Weighter归一化的结果进行相加，再进行排序，选择最大的结果。

图6 Cinder Weighters

不同的Cinder Volume会定期将自己的信息（例如，Backend name、Pool name、Pool大小、可用容量、已使用容量、特性等）上报给Cinder Scheduler，Cinder Scheduler进行Filter和Weighter是需要这些信息，超过一定时间未上报（时间可以在配置文件设置），或者Cinder Scheduler和Cinder Volume服务器时间不同步，Cinder Scheduler会将Cinder Volume标记为disabled，不再进行调度。Cinder Scheduler只会在创建卷或迁移卷时使用，用于选择目标Cinder Volume，卷的更新和删除，不经过Cinder Scheduler，直接走Cinder Volume。

Cinder Volume（Driver）：每个后端存储根据需要启动一个或多个Cinder Volume服务，命名为Host@Backend#Pool，作为唯一标识。Cinder Volume收到请求后，可能是卷的CRUD，也可能是其他操作（例如快照CRUD、replication、attach/detach等），会调用对应的driver去后端存储上（例如，Ceph、VMAX）执行CRUD操作，可能是通过API方式，也可能是通过SSH方式，登陆到后端存储的管理口进行操作，后端存储执行CRUD操作后，会将结果反馈给driver，driver修改Cinder数据库中volume信息。Attach和Detach卷时，如果是FC SAN，还要调用FC zone manager去FC交换机上设置multipath，确保多路复用，提高可用性。每个driver都会定期去后端存储查询信息（例如，Pool大小、可用容量、已使用容量、特性等），定期上报到Cinder Scheduler中去。

高可用架构：高可用就是用冗余资源来解决系统的可用性，确保故障发生时RTO和RPO尽可能小。一般有两种实现方式，一是多活（Active/Active：A/A），二是主备（Active/Passive：A/P），对于无状态的服务，做成A/A，对于有状态的服务，做成A/P。有状态是指操作受本地数据影响（例如：本地保存登录session，后续操作必须依赖这个session），无状态则是操作不依赖本地数据。对于有状态的服务，要做A/A的话，需要把服务从有状态服务调整为无状态服务，怎么改造的，本地数据存放到公共地方。Cinder API、Scheduler、Volume都是是无状态服务，一般Cinder API和Scheduler部署在一起，通过A/A部署都三台机器上，同一个后端存储对应一个或多个Cinder Volume，不同的后端存储对应不同的Cinder Volume。根据实际需要对Cinder Volume进行加锁，早期只有本地锁，同一个存储后端启动一个Cinder Volume，做成A/P部署，有了分布式锁后，同一个存储后端可以启动多个Cinder Volume，做成A/A部署，提高Cinder Volume的并发性。锁的作用，一是避免不同的Scheduler可能会调度到同一个Cinder Volume上，二是避免A/A部署的Cinder Volume会同时操作后端存储，并发操作带来数据不一致性。

五、社区贡献之路：

你可以向OpenStack社区提交Patch，包括：blueprint、bugfix、document等。

图7 OpenStack贡献之路

注册账号：首先，登陆https://launchpad.net/，注册一个launchpad账号，签订CLA；其次，登陆https://review.openstack.org/，注册一个reviewer账号；最后，登陆https://github.com/网站，注册一个github账号。

提交Patch：首先，从OpwnStack官网下载cinder源代码（git clone https://github.com/openstack/cinder.git）；其次，根据实际情况修改源代码，可以是bp、bugfix、doc（OpenStack文档也是通过rst\inc\yaml文件组织的）；然后，在本地进行单元测试；最后，提交Patch（git commit & git review）。

Code Review：提交完代码后，你在https://review.openstack.org网站就可以看到你提交的内容。先经过Jenkins Check、Zuul、以及一些第三方CI检查，没问题后，Verified标记为1（否则标记为-1），普通reviewer可以进行review，打分-1或+1，core reviewer可以进行review，打分-2或-1或+1或+2，只有Code-Review为+2且Workflow为+1后，Zuul和Jenkins Gate会进行检查，如果没问题，就merge到github的master分支中去。每个reviewer都有自己的工作安排，所以不要主动找reviewer来review你提交的代码，等着就行，一般会有人来review你的代码的，可能是一个大牛reviewer。路漫漫兮其修远，review过程略长，也许一个patch要review几个月才能merge。

图8 Code Review流程

查看你的贡献排名：登陆https://github.com/openstack/cinder，查看你成功提交合并的源代码。登陆http://stackalytics.com/，查看你的贡献排名情况，可以按review、commits、LOC等指标进行排名，从此你被暴露在世界的眼光之下，你成名了。

图9 OpenStack全球贡献统计

六、关注Cinder动态：

Cinder的基本框架已经完善，如下工作正在进行：

Fix bug：bug是无法避免的，等你的慧眼来识别。

Driver CRUD：新driver加入Cinder，不符合要求的driver从Cinder中移除，已有的driver增加新特性。

Policy in code：目前对于每个操作进行权限检查，权限都配置在policy.json文件中，操作太多后，policy.json文件会变得臃肿，且牵一发而动全身，计划在policy.json中配置基本的操作权限，在不同的代码模块中配置特殊的操作权限。

Doc migration：之前有单独的文档项目管理了所有组件的文档，因为core流失问题，人力资源不足，所以文档项目只保留了基础的文档管理职责，具体组件相关的文档，分散到各个组件负责。

Placement：统一资源调度组件Placement正在成熟，将会从Nova中分离出来（Pike版本还没有），等分离出来后，Cinder可以使用Placement进行资源调度，一些通用Filter可能要取消了。

 

七、持续学习之道：

1、关注OpenStack官网：

[1] https://docs.openstack.org     

[2] https://developer.openstack.org

[3] https://review.openstack.org   

[4] https://launchpad.net

[5] https://github.com/openstack   

[6] http://stackalytics.com

 

云银联盟金融云：让金融IT云化更简单！