CinderBrick

我们想要解决的问题

• 现在有多个项目包含与存储相关的代码
• 资源和配额的使用在每个项目中独立管理
• 可用区对于调度来说不够精细（例如，我希望实例使用机架内或节点上的存储）
• 希望能够为可能需要它的实例快速部署本地或机架内存储（例如，超高性能数据库实例等）
• 关键在于，他们可能没有高性能 SAN 类型存储，Cinder 通常会部署那种存储，他们希望利用计算节点上的本地存储

节点，甚至与计算节点位于同一机架内的 RAID 等（即，最大限度地减少网络跳数/延迟）

重点

强调管理以下内容，而不是让 Nova 和 Cinder 都重复这些事情（想想 LOCAL）

• lvm
• qcow
• vdi

非重点（目标不包括）

• iSCSI

我们已经在 H 中完成了大部分工作，并且它确实消除了大量的重复，所以继续使用它。

但是，那是 iSCSI 组件，例如 tgt 和 intiiator。重复的存储相关代码

这是一次胜利，但实际上并非重点

• 后端驱动程序

这个想法不是将所有后端驱动程序都从 Cinder 移动到一个库中，这样做没有任何好处

例如，如果您正在将 iSCSI 附加到计算节点，它仍然应该由 Cinder 提供

用例示例

• 管理员可以在 OpenStack 集群中的系统上创建各种存储资源
• 租户然后可以显式或隐式地请求配对或基于位置的最佳匹配（实例/卷分组/配对）

显式示例：“nova boot --flavor xxx --image yyy --local-storage <size-in-Gig> my-special-instance”

隐式示例：“nova boot --flavor ZZZ --image my-special-instance”（其中实例的风味可能包含存储大小等）

这可能是 nova 调用 Cinder，然后 Cinder 在适当的节点上部署资源（因此 brick 安装在计算/其他节点上，以便 brick 成为后端）

最佳示例（Vish 在上次峰会上展示）

 : request comes in to nova ->
 : nova gets list of potential compute nodes ->
 : nova calculates best X nodes and creates reservations ->
 : nova asks cinder to create volume on best from list ->
 : cinder creates volume and returns selected host ->
 : (clear reservation and retry excluding the original nodes on failure)
 : nova clears reservation and boots instance on selected host
 : (cleanup volume and retry entire operation on failure)

上次讨论的 etherpad 链接

https://etherpad.openstack.org/havana-cinder-local-storage-library