Manila/Replication Design Notes

旧设计页面

此页面用于帮助设计 OpenStack 之前版本的一个特性。该特性可能已经实现，也可能没有实现。因此，此页面可能不会更新，并且可能包含过时的信息。上次更新时间为 2015-10-21

简介

复制的设计尚未完成。我们对该特性有一个愿景，并且正在努力定义细节。在收集到反馈后，我们将将其重新格式化为设计文档。

数据面临的威胁

硬件故障
网络故障
电源故障
自然灾害（火灾、洪水、飓风、流星）
意外损坏（错误、人为失误）
恶意用户（病毒、黑客、心怀不满的员工）

保护数据的解决方案

高可用性存储系统
- 策略
  - RAID/擦除编码（防止介质故障）
  - 集群（防止组件故障）
  - 多路径网络拓扑（防止连接故障）
  - 冗余电源（防止电源故障）
- 优点
  - 对客户端透明
  - 零 RPO/RTO（除了可能有一个短暂的暂停）
- 缺点
  - 通常距离有限（对站点范围内的故障防御较弱）
- Manila
  - HA 存储解决方案无需更改即可适应 Manila
  - 使用“共享类型”来指示某些存储后端是高可用的
备份
- 策略
  - 磁带归档（在过去）
  - 虚拟磁带归档（Amazon Glacier 或类似服务）
  - 本地快照（标准的 Cinder/Manila 功能）
  - 远程快照（将快照复制到对象存储，如 Cinder 备份）
- 优点
  - 可能非常便宜
  - 存储多个时间点（防止损坏/恶意破坏）
- 缺点
  - RPO 通常较高
  - 本地快照无法防止设备/站点故障
  - 远程快照通常必须在可访问之前进行还原——RTO 较高
- Manila
  - 本地快照今天已实现
  - 远程快照（又称“备份”）计划在未来实现
复制
- 策略
  - 同步镜像
  - 异步镜像
- 优点
  - 可以处理更远的距离
  - 可以提供非常低的 RPO/RTO
- 缺点
  - 对网络客户端不透明
- Manila
  - 这就是我们正在提议的！！！

提案概述

从用户体验开始
- 如果它不能解决用户的问题，那么其余的设计就没有意义了
也要考虑管理员的需求和责任
考虑供应商/驱动程序作者和实际问题
- 设计有意开放，以便尽可能方便供应商实施

用户体验

用户将能够通过指定共享类型来创建“复制”共享和非复制共享
- 所有现有共享都是非复制的
- 管理员必须专门创建包含 replication extra_spec 的共享类型
- 开放问题——“replication” extra spec 是否应该对租户可见？
  - 我们可以像 driver_handles_shares_servers 对租户可见一样来做
  - 或者：依赖管理员来告知哪些类型是复制的，并依赖“replicated”属性在创建后出现在共享中
- 开放问题——“replication” extra spec 应该叫什么？
  - 供应商应该可以自由地为不同类型的复制提供额外的功能，只是
  - 必须有一个标准的 capability/extra_spec 来控制 Manila 复制功能
复制的共享将具有一个 replicated=true 标志，由 API 返回
复制的共享还将具有一个 replication_state 字段
- 同步 - 稳定状态 - 共享数据正在被复制到 1 个或多个辅助控制器
- 不同步 - 稳定状态 - 共享数据没有被复制
- 重新同步 - 过渡状态 - 后端正在尝试重新建立复制
- 故障转移 - 过渡状态 - 共享正在更改为不同的主节点
两个新的租户可见 API
- 故障转移
  - 只能对处于同步状态的共享调用
  - 导致现有的导出位置被删除（必须先卸载以避免数据丢失）
  - 导致共享进入故障转移状态
  - 导致出现新的导出位置（可能位于另一个位置的不同存储控制器上）
  - 预计无论托管共享的存储控制器在线还是离线，都能成功
  - 成功故障转移后，共享可能处于 2 种状态
    - 同步——如果主存储控制器在线并且后端能够从辅助控制器反向复制
    - 不同步——也许主存储控制器离线了，或者后端无法立即从辅助控制器重新建立复制
- 重新同步
  - 只能对处于不同步状态的共享调用
  - 导致共享进入重新同步状态
  - 导致后端尝试重新建立复制（如果可能）
  - 成功后，共享进入同步状态
  - 失败后，共享返回到不同步状态
    - 如果主节点仍然关闭，则预计会发生这种情况
复制的共享将具有一个 primary_location=True/False 标志
- 指示共享是否由原始（主）存储控制器提供服务
- 故障转移后，此字段将被设置为 False，以指示共享由辅助存储控制器提供服务
  - 辅助位置可能不具备主位置的所有功能
  - 例如，共享类型可能会指定 SSD 磁盘 extra_spec，但辅助存储控制器可能具有旋转磁盘
    - 这由管理员配置他想要的方式
    - Manila 不调度辅助位置，所以这应该没问题
- 如果共享不由主存储控制器提供服务，则应始终尝试将其移回主节点（如果可能）
  - 该提案允许复制到多个位置（由管理员选择，如果后端允许）
  - 用户不知道有多少个复制位置或他们的共享位于哪个位置——他们只知道它是否位于主节点

管理员体验

管理员今天的任务
- 安装/配置硬件
- 了解基础设施的物理布局
- 了解网络连接和基础设施的逻辑拓扑
- 考虑故障域和故障情况下的应急措施
  - 如果托管 Manila 的存储控制器发生故障，管理员能做的很少，除了尝试将其恢复在线
- 配置 Manila
  - 设置存储控制器
  - 安装软件
  - 在 manila.conf 中配置后端（通常是主机名、登录名、密码等）
Manila DR 的管理员新职责
- 为复制选择主/辅站点
  - 可以在机架之间、通道之间、楼层之间、建筑物之间、城市之间或大陆之间
- 决定是进行对称（主动/主动）还是不对称（主动/被动）复制
  - 单个共享始终具有一个主（可访问）位置和一个辅助（不可访问）位置
  - 主动/主动是指具有 2 个控制器，其中一些主节点位于每个控制器上，并且它们相互复制
  - 主动/被动是指将所有主节点放在一个控制器上，将所有辅助节点放在另一个控制器上
- 找到支持复制的驱动程序
  - 通用驱动程序支持复制非常重要
    - 我们希望向每个人提供此功能
    - 它需要用于门控测试此功能
    - 正在寻找志愿者来帮助改进通用驱动程序
- 设置具有足够带宽以适应镜像的硬件
- 配置 Manila
  - 没有用于复制的新配置标志
  - 每个驱动程序都可以决定如何表达复制关系
    - 假设复制很可能发生在相同供应商的后端之间
    - 这可能像一个包含可以复制到的其他后端名称的列表的新配置选项一样简单
  - 如果站点故障可能会影响控制器节点，那么拥有 Manila 的 HA 配置会是一个好主意
- 响应中断
  - 管理员通常比租户拥有更多关于实际基础设施的信息
  - 管理员应在发生中断时与租户沟通
  - 如果管理员认为给定中断的性质适合故障转移，他可以/应该启动它
    - 有时中断可能很短暂，等待主节点恢复比故障转移更好
      - 这就是我们不提议自动故障转移的原因之一
    - 开放问题：如何优化大量共享的故障转移？
    - 用户可以自行启动故障转移，但我们认为这只适用于测试目的
- 修复中断并恢复
  - 在中断结束时，管理员应重新同步所有不同步的共享
    - 开放问题：如何优化大量共享的重新同步？
  - 应通知用户中断已结束并且可以安全地故障转移回主节点
  - 管理员不应单方面故障转移共享
    - 故障转移共享会导致短暂的连接丢失
    - 最好让用户选择最不具破坏性的时间
- 永久中断
  - 有时中断时间太长，以至于选择新的复制站点而不是重建主节点更有意义
    - 建筑物因火灾/洪水/龙卷风/流星而毁坏
  - 管理员/用户执行故障转移到辅助节点，共享进入不同步状态
  - 管理员更改 manila.conf 中的复制关系列表并重新启动 manila-share，调用 update_replication API
  - 共享进入重新同步状态（update replication 就像 resync++）
  - 最终共享再次变为同步
  - 如果当前位置不是新的主位置，用户可以故障转移到新的主节点

驱动程序维护者/供应商关注点

复制不是必需的功能
- 只有当后端通告“replication”capability 时才需要工作
仍然只有 1 行数据库/1 个 UUID 用于每个共享
只有 3 个新的 DB 字段
- Replicated=true/false
- Replication state=同步/不同步/重新同步/故障转移中
- Primary_location=true/false
驱动程序应使用驱动程序私有数据功能存储有关共享复制的任何所需信息
驱动程序有 3 个新方法
- failover_share
  - 在管理器删除现有的导出位置后调用
  - 管理器在调用此方法之前将共享状态设置为故障转移中
  - 驱动程序应执行任何必要的操作以使辅助节点可访问
    - 主节点可能仍然可访问，也可能不可访问
    - 预计故障转移在两种情况下都能成功
  - 驱动程序应在模型更新中返回新的导出位置
  - 驱动程序可以更新共享的 host 字段，如果不同的后端应该在故障转移后拥有该共享
  - 驱动程序可以立即反向初始化复制，如果主节点可访问
  - 驱动程序应使用模型更新将复制状态更新为同步或不同步
    - 同步表示故障转移成功并且已重新建立了反向复制
    - 不同步表示故障转移成功但未重新建立复制
  - 失败时，共享进入 ERROR 状态
- resync_share
  - 管理器在调用此方法之前将共享状态设置为重新同步中
  - 驱动程序应尝试重新建立复制
  - 驱动程序应使用模型更新将复制状态更新为同步或不同步
    - 同步表示重新同步成功
    - 不同步表示重新同步失败
- update_share_replication
  - 仅限管理员 API
  - 通知驱动程序拓扑已更改，应清理过时的关系并创建新的关系
  - 如果旧的 primary_location 不再是复制关系的一部分，驱动程序应设置新的 primary_location
    - primary_location 仅在复制拓扑更改时才会更改
    - 开放问题：驱动程序如何知道将哪个位置设为主节点？
  - 也执行 resync 所做的一切
对现有方法的更改
- create_share
  - 如果共享类型具有该 extra spec，则管理器将在共享上设置 replication=true
  - 驱动程序应根据需要设置复制并在模型更新中将复制状态设置为同步
- ensure_share
  - 此方法在驱动程序启动时为每个共享调用
  - 除了其他清理工作外，复制状态为重新同步或故障转移中的共享应设置为稳定状态
驱动程序具有很大的灵活性
- 替代拓扑
  - 复制到多个其他站点
  - 扇出复制或复制链
- 辅助后端
  - 两个 Manila 后端可以相互复制
  - 一个 Manila 后端可以管理两个控制器
  - 后端可以有一个可能的复制目标列表并选择一个（但不涉及 Manila 调度器）
- 同步/异步 RPO/RTO 时间
  - 关于不同类型的复制的所有选项都可以是（特定于驱动程序）后端功能
- 驱动程序可以积极或懒惰地修复损坏的复制关系
- 所有这些灵活性的目的在于使各种技术都能适应该设计

API

三个新的 REST API
- 用户界面：故障转移、重新同步
- 管理员界面：更新复制
- 验证共享状态并调用管理器 RPC
创建
- 根据 share_type 设置复制状态
共享视图的附加字段
- Replicated=true/false
- 复制状态
- Primary_location=true/false

调度器

无更改
现有的 extra_specs/capabilities 逻辑确保为复制共享选择适当的后端

共享管理器

添加用于故障转移/重新同步/update_replication 的 RPC
在调用驱动方法之前实现适当的复制状态更改
在故障转移之前清除 export_locations
添加新的驱动入口点
验证关于复制状态的模型更新
确保更改共享的 host 字段不会导致问题

Manila/Replication Design Notes

目录

当前设计页面位于 Manila/design/manila-mitaka-data-replication

简介

数据面临的威胁

保护数据的解决方案

提案概述

用户体验

管理员体验

驱动程序维护者/供应商关注点

API

调度器

共享管理器