Manila/Replication Use Cases
|
旧设计页面
此页面曾用于帮助设计 OpenStack 的先前版本中的一项功能。该功能可能已经或尚未实现。因此，此页面可能不会更新，并且可能包含过时信息。上次更新时间为 2015-10-21 |
当前设计文档 Manila/design/manila-mitaka-data-replication
已回答的问题
问：我们允许从哪里复制到哪里？是云内复制还是云间复制？我们是否允许复制到不由 Manila 管理的事物？
答：云内复制。复制到 Manila 外部的事物可以提供更多自由度，但价值明显降低，因为我们几乎无法自动化灾难恢复/回退过程。对于涉及 Manila 外部复制的用例，我们需要涉及其他具有更广泛/范围的工具来管理该过程。
问：我们是否支持非计划故障转移？我们是否支持计划故障转移？故障转移是否具有破坏性？
答：故障转移可以是计划的或非计划的，但它们在数据层始终具有破坏性。通过应用程序集成，可以在应用程序层使其变为非破坏性，但不幸的是，我们选择不在数据路径中使用任何中间技术（如 virtfs），这意味着我们没有非破坏性故障转移的选项。
问：谁配置复制？管理员？最终用户？Manila 调度器？
答：最终用户。在原始设计中，我们假设实际的复制关系应该对最终用户隐藏，但这与我们添加到 Manila 的 AZ 概念不太匹配。如果用户需要控制其数据的原始副本所在的 AZ，那么他们也需要控制其他副本所在的位置。这意味着管理员的工作是确保对于任何已复制的共享类型，它可以从任何 AZ 复制到任何其他 AZ。
问：谁触发故障转移？是管理员按下的手动按钮吗？Manila 是否可以自动故障转移？如果是，何时？最终用户是否可以控制故障转移？
答：故障转移是手动触发的，由管理员或用户触发。一般来说，管理员发起故障转移更合适，因为管理员更了解中断的性质。但是，最终用户也需要测试故障转移，因此他们需要能够自行发起共享的故障转移。
问：在复制期间（在故障转移之前），辅助副本是否可见/可访问？
答：是的，但可能存在重大限制。某些后端可能不支持访问已复制共享的辅助端。某些后端可能允许访问，但仅限只读。我们至少知道有一个后端可以支持对辅助端进行写入访问（在这种情况下，将其称为辅助端实际上并不准确，因为它更像是一种主动-主动关系）。Amazon 的 EFS 具有主动-主动复制的模型，所以我们不想禁止这种模式。
问：故障转移的粒度是什么？整个后端？单个池？
答：单个共享。没有技术原因阻止逐个共享地进行故障转移/回退。为了让管理员的生活更轻松，我们还必须支持整个后端故障转移（在实际灾难中，这对于最大限度地减少停机时间至关重要）。能够进行单个共享故障转移很好，因为它允许测试 DR 系统，而不会触发影响用户的中断，因为故障转移具有破坏性。
未回答的问题
存在一些主要的未回答问题（或调查领域）。
1) 是否无法实现非破坏性故障转移？我很乐意发现我们最初的直觉是错误的，因为这将改变设计的许多方面。值得花时间集思广益并研究该领域的可能性。到目前为止，最有希望的想法包括
- 使用 VirtFS 来调解文件系统访问，并以此实现非破坏性故障转移
- 在客户机内部使用某种代理来调解文件访问
2) 我们如何处理灾难恢复和故障转移后的恢复？假设故障转移成功，并且原始主副本已修复，回退将导致另一个中断。我们如何协调它以最大限度地减少痛苦和损失？
3) 假设故障转移的破坏性是不可避免的，我们如何投资使其在应用程序级别上不那么痛苦？应用程序静默和挂载自动化可以使故障转移对至少一小部分应用程序而言变为非破坏性。
4) 副本是否可以具有不同的 share_type？
用户希望在具有与原始共享所在后端不同的功能的后端上创建共享副本，这是一种有效的使用案例。例如，副本可能需要在成本较低的后端上。在这种情况下，副本是否可以具有完全不同的 share_type？
“目前”，我们继承共享的 share_type，并认为复制必须在对称的条件下进行，即两个后端都具有类似的功能。
5) 我们是否允许驱动程序限制可用后端之间的复制支持？
后端可能仅支持与其他兼容后端进行复制。因此，它们必须向调度器报告某种信息，以便在为现有共享创建副本时，调度器将使用该信息来安排副本的创建。应该提供什么信息？
6) 如何在副本/共享实例之间持久化访问规则？
- 所有副本是否应用相同的访问规则？（目前正在进行中）
- 访问规则是否仅应用于“活动”副本？
7) 迁移如何影响已复制的共享？
8) API 端点
9) 在显示已复制的共享时，应该显示哪些导出位置？
- 来自所有可用“活动”副本的所有导出位置（目前正在进行中）
- 活动实例的导出位置
- 位于活动实例的 AZ 内的导出位置
10) 我们在哪里存储“replication_change”状态？
- 在我们要提升的实例的“status”上（目前正在进行中）
- 在已复制共享的所有副本实例上
- 作为共享本身上的新状态
11) 'replica_state' 字段应为 'healthy' 或 'error'，因为当前选项 'in-sync' 和 'out-of-sync' 可能表示同步和异步复制。
- 与 Ben 在 IRC 上的讨论
- “想法是重新定义 in-sync 为“在异步复制的 RPO 保证范围内””
- 用户应该通过 share type 中的“description”来了解它是异步复制还是同步复制。
- “in-sync/out-of-sync 应该传达的主要内容是副本是否“足够好”，可以故障转移到它”
12) 共享上的 'replication' 字段应限定复制是同步还是异步，因此选项应为 ["readable_sync", "readable_async", "writable", "dr_sync", "dr_async"]
- 与 Ben 在 IRC 上的讨论
- 用户应该通过 share type 中的“description”来了解它是异步复制还是同步复制。
