更精细的复制 (Tiramisu)¶

https://blueprints.launchpad.net/cinder/+spec/replication-cg

在 Mitaka 版本中，实现了复制 v2.1 (Cheesecake) [1][2]，以支持当整个宿主机可以故障转移到辅助站点时的灾难恢复场景。Cheesecake API 面向管理员。

在 Mitaka 中期会议上，Cinder 团队决定在 Cheesecake 实现之后，Tiramisu 将是下一步。Tiramisu 是面向租户的、具有更精细粒度的复制 API 的代号。它赋予租户更多控制权，可以控制应该一起复制的内容。

问题描述¶

复制 v2.1，作为 Mitaka 中的管理员 API 实现，旨在解决当整个后端必须故障转移到辅助站点上的后端时的真正 DR 场景。这绝对是一个非常重要的用例。

还有其他情况，客户也希望对复制的粒度有更多控制权。能够复制一组卷并在不影响整个后端的情况下测试故障转移也是一个期望的功能。需要一个面向租户的 API 来满足此要求，因为只有租户知道哪些卷应该组合在一起以用于他的/她的应用程序。

诚然，您可以通过创建包含复制信息的卷类型并创建该卷类型的卷来使用 Cheesecake 进行基于组的复制，因此所有使用该类型创建的卷都属于同一组。那么 Tiramisu 能做什么 Cheesecake 无法做到的呢？

在 Tiramisu 中，将使用组结构来管理要一起复制的卷组，以便于管理。

通用卷组规范 [3] 中设计的组结构将提供面向租户的组 API，允许租户决定应该将哪些卷组合在一起，以及何时以及应该将哪些卷添加到或从组中删除。
将添加启用复制功能，允许租户决定何时将所有用于特定应用程序的卷添加到组中并发出复制过程的开始信号。
将添加禁用复制功能，允许租户决定何时停止复制过程并对组进行调整。
将添加故障转移复制功能，以便租户测试组的故障转移并确保应用程序的数据在故障转移后不会受到损害。
租户可以在不影响整个后端的情况下测试故障转移。
租户可以在灾难发生时决定何时以及是否进行故障转移。

如果租户已经使用 Tiramisu API 故障转移了一个组，然后发生了真正的 DR 情况，仍然可以使用 Cheesecake API 来故障转移整个后端。已经故障转移的卷组不应该再次故障转移。Tiramisu 将使用为 Cheesecake 设计的配置选项，例如 replication_device。

用例¶

一个应用程序可能将数据库存储在一个卷上，将日志存储在另一个卷上，以及其他相关文件存储在其他卷上。对于某些应用程序，能够一起复制应用程序使用的所有卷非常重要。因此，拥有一个一起复制的卷组的概念是有价值的。
租户希望控制在故障转移期间应该组合哪些卷，并且只有租户知道哪些卷属于同一个应用程序，应该放入同一个组中。
租户可以通过在将应用程序使用的所有卷添加到组后执行启用复制来确定何时开始组的复制过程。
租户可以通过在需要对组进行调整时执行禁用复制来确定何时停止组的复制过程。
租户希望能够验证在灾难真正发生之前，数据在故障转移后不会受到损害。他/她只关心自己的应用程序，并希望能够测试自己卷组的故障转移，而不会影响整个后端。
租户希望在灾难发生时决定何时以及是否进行故障转移。

提议的变更¶

通用卷组设计在单独的规范 [3] 中，并且此规范依赖于它。组操作 API 的 URL 来自通用卷组规范

‘/v3/<tenant_id>/groups/<group_uuid>/action’

将添加以下操作以支持卷组的复制。

enable_replication
disable_replication
failover_replication
list_replication_targets

如果一个卷“正在使用”，则需要将“allow-attached-volume”标志设置为 True，才能使 failover_replication 正常工作。这是为了防止租户滥用故障转移 API，并在强制故障转移附加卷时造成问题。租户或管理员应该在故障转移之前分离卷，或者由更高层项目（例如 Karbor）处理。

组类型需要具有以下 group_spec 以支持复制

'group_replication_enabled': <is> True
or
'consistent_group_replication_enabled': <is> True

驱动程序还需要报告 group_replication_enabled 或 consistent_group_replication_enabled 作为功能。

Karbor 或另一个数据保护解决方案可以是 Cinder 中复制 API 的使用者。流程如下

管理员配置 cinder.conf。
管理员在 Cinder 中设置支持复制的组类型和卷类型。
租户在 Cinder 中创建一个支持复制的组。
租户在 Cinder 中创建卷并将其放入组中。
在 Karbor 中，租户选择将哪些资源放入保护组中。对于 Cinder 卷，Karbor 可以检测所选卷是否属于复制组，并自动选择该组中的所有卷。例如，Karbor 可以检查 Cinder 卷组是否在其组规范中具有 group_replication_enabled 或 consistent_group_replication_enabled。
在通用卷组规范 [3] 中有 API 用于创建/删除/更新/列出/显示组。Karbor 或另一个数据保护解决方案可以使用这些 API 来管理租户的组。
在 Karbor 中，可以根据保护策略执行保护操作。如果保护操作触发故障转移，Karbor 可以调用 Cinder 的复制 API 来故障转移复制组。
正如在 Cinder Newton 中期会议上讨论的那样 [4]，驱动程序可以将 replication_status 作为 volume_stats 的一部分报告。卷管理器将检查 volume_stats 中的 replication_status，如果 replication_status 为 error，则更新数据库。

备选方案¶

不要添加通用的卷组结构。相反，只需使用现有的一致性组来实现组复制。

数据模型影响¶

无

REST API 影响¶

将添加组操作

enable_replication
disable_replication
failover_replication
list_replication_targets

来自通用卷组设计的组操作 API 的 URL：: ‘/v2/<tenant_id>/groups/<group_uuid>/action’

启用复制
- 方法：POST
- V3 的 JSON 模式定义
```
{
    'enable_replication': {}
}
```
- 正常响应代码：202
- 错误响应代码：400, 403, 404
禁用复制
- 方法：POST
- V3 的 JSON 模式定义
```
{
    'disable_replication': {}
}
```
- 正常响应代码：202
- 错误响应代码：400, 403, 404

故障转移复制

方法：POST
V3 的 JSON 模式定义

{
    'failover_replication':
    {
        'allow_attached_volume': False,
        'secondary_backend_id': 'vendor-id-1',
    }
}

正常响应代码：202
错误响应代码：400, 403, 404

列出复制目标

方法：POST
V3 的 JSON 模式定义

{
    'list_replication_targets': {}
}

响应示例

{
    'replication_targets': [
        {
            'backend_id': 'vendor-id-1',
            'unique_key': 'val1',
            ......
        },
        {
            'backend_id': 'vendor-id-2',
            'unique_key': 'val2',
            ......
        }
     ]
}

非管理员的响应示例

{
    'replication_targets': [
        {
            'backend_id': 'vendor-id-1'
        },
        {
            'backend_id': 'vendor-id-2'
        }
     ]
}

安全影响¶

无

通知影响¶

将添加用于启用、禁用和故障转移复制的通知。

其他最终用户影响¶

python-cinderclient 需要支持以下操作。

enable_replication
disable_replication
failover_replication
list_replication_targets

性能影响¶

无

其他部署者影响¶

无

开发人员影响¶

驱动程序开发人员需要修改驱动程序以支持 Tiramisu。

实现¶

负责人¶

主要负责人: xing-yang
其他贡献者: jgriffith

工作项¶

更改功能报告。驱动程序需要报告 group_replication_enabled 或 consistent_group_replication_enabled。
添加组操作以支持组复制。

依赖项¶

该功能建立在通用卷组规范之上，该规范已经合并并实现。

测试¶

将添加新的单元测试来测试更改后的代码。

文档影响¶

需要进行文档更改。

参考资料¶

[1] 复制 v2.1 Cheesecake 规范: https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/cheesecake.html
[2] 复制 v2.1 Cheesecake Devref: https://github.com/openstack/cinder/blob/master/doc/source/devref/replication.rst
[3] 通用卷组: https://github.com/openstack/cinder-specs/blob/master/specs/newton/generic-volume-group.rst
[4] Newton 中期会议: https://etherpad.openstack.org/p/newton-cinder-midcycle-day3

更精细的复制 (Tiramisu)