Cinder Volume Active/Active 支持 - 总体描述¶
https://blueprints.launchpad.net/cinder/+spec/cinder-volume-active-active-support
目前 cinder-volume 服务只能以 Active/Passive HA 方式运行，本规范提出了一种支持 Cinder Volumes 中 Active/Active 配置的可能方案。
本规范仅提供问题的总体描述，列举我们需要解决的不同问题，而不会深入研究细节。它更像是对问题的鸟瞰图。
每个具体问题都将有自己的规范，详细描述问题并提出解决方案。
问题描述¶
目前 cinder-volume 服务仅接受 Active/Passive 高可用性配置，为了支持 Active/Active 配置，需要进行许多更改。
API 竞争¶
在当前代码的 API 节点上，我们容易出现影响数据库资源的竞争，在使用 Active/Active 配置时，这种情况会更加严重。
本地管理器锁¶
在 volume 节点的管理器代码中，我们有多个本地锁，以防止多个 green 线程在特定操作上访问相同的资源。
此锁定仅限于节点本地，不扩展到其他节点，因此我们需要解决相同集群的 volume 节点之间的互斥访问问题。
任务分发¶
Cinder 没有集群的概念，只有主机概念，并且每个主机都实现特定的后端/服务。需要一种机制将同一集群的主机分组在相同的概念单元下，同时保留集群中节点各自的身份，以便在崩溃节点清理时进行区分。
清理¶
目前只有一个节点可以处理特定的后端，因此可以处理该后端包含的资源，启动时由该节点本身完成清理。如果节点无法启动，资源处于停滞状态，这也不是什么大问题。
在 Active/Active 部署中，情况有所不同，因为多个节点共享相同的存储后端，并且节点只能清理其死亡/故障时正在处理的节点上的资源。
即使某个节点无法恢复，也需要进行适当的清理，因为同一集群中的其他节点仍然可以管理这些资源。
数据损坏预防¶
由于多个节点将访问相同的存储后端，因此我们必须格外小心，不要访问其他节点正在访问的资源。
更相关的情况是，当我们与 DB 失去连接并且无法再发送 Service Heartbeats 时，因为 Scheduler 的清理过程（在 Cleanup 提出的更改中说明）将会生效，并且我们可能会有两个不同的节点访问相同的资源，一个是因为它仍在处理它，另一个是因为它正在尝试进行清理。
驱动程序锁¶
某些驱动程序需要对某些操作或访问相同资源进行互斥访问。
目前这种互斥访问是通过与管理器相同的方式使用本地锁来完成的，它们需要能够在多个节点访问相同的存储后端时工作。
用例¶
那些对云的运行时间有硬性要求、SLA 或其他原因，或者对吞吐量有更高要求的运营商，希望能够配置其部署为 Active/Active 配置。
提议的变更¶
API 竞争¶
将使用 compare-and-swap 更新到 DB 来移除 API 节点上的竞争。
任务分发¶
任务分发将向 cinder 添加集群的概念，并使用集群而不是现在的主机，通过主题消息队列发送任务。
清理¶
清理将跟踪具有正在进行的操作的资源，并在 Scheduler 以及 Volume 节点上具有清理机制。
节点上的清理将在初始化时进行，就像现在一样，但我们还将在 Scheduler 上有一个自动清理作业，用于主机名未启动的情况。
自动清理机制默认情况下将被禁用，并且可以手动触发它。
数据损坏预防¶
停止从 Message Broker 接收新任务，并停止所有正在进行的操作，这样我们就不会再访问存储后端上的资源。
管理器本地锁¶
默认解决方案将使用带有 TooZ 作为抽象层的 DLM。
另一种解决方案，最初将作为“很好拥有”来保留，将适用于不想安装 DLM 解决方案并且正在使用不需要分布式锁的 Active-Active 配置的驱动程序的系统。此解决方案使用 DB 锁机制替换 c-vol’s 管理器上的本地文件锁，使用 workers DB 表（由 Cleanup 更改引入）。
驱动程序锁¶
我们将使用带有 TooZ 作为抽象层的 DLM 解决方案
备选方案¶
对于我们需要修复的每个问题，以及它们在各自的规范中讨论的许多替代方案，除了创建扩展实现 管理器本地锁 的锁定机制的驱动程序锁的替代方案外。
数据模型影响¶
在各自的规范中讨论。
REST API 影响¶
在各自的规范中讨论。
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
在各自的规范中讨论。
其他部署者影响¶
在各自的规范中讨论。
开发人员影响¶
无
实现¶
负责人¶
在各自的规范中讨论。
工作项¶
API 竞争
任务分发
清理
数据损坏预防
管理器本地锁
驱动程序锁
依赖项¶
无
测试¶
在各自的规范中讨论。
文档影响¶
在各自的规范中讨论。
参考资料¶
无
