跳转到： 导航, 搜索

OpenStack 级联解决方案

拆分为两个开源项目

级联层被拆分并解耦为“Tricircle”项目 (https://wiki.openstack.org/wiki/Tricircle) 和 “Trio2o”项目 (https://wiki.openstack.org/wiki/Trio2o)。

OpenStack 级联解决方案是这两个开源项目的版本 1，并且已经商业交付并在许多公共、混合和私有云中运行。

概述

OpenStack 级联解决方案专为多站点 OpenStack 云集成而设计，并通过这种方式解决 OpenStack 的可扩展性问题，例如，一个拥有百万级虚拟机且地理分布在多个数据中心的云。

  • 父 OpenStack 暴露标准的 OpenStack API
  • 父 OpenStack 使用标准的 OpenStack API 管理许多子 OpenStack
  • 每个子 OpenStack 充当类似 Amazon 的可用区，并被父 OpenStack 隐藏
Cascading01.png
  • 级联 OpenStack：父 OpenStack，提供 API 和调度以及级联 OpenStack 的编排
  • 级联 OpenStack：子 OpenStack，配置虚拟机、卷和虚拟网络资源


级联 OpenStack 的作用是充当虚拟资源（VM、卷、网络..）的寻址和路由，到相应的级联 OpenStack，虚拟资源在那里分配和互连。级联 OpenStack 仅成为一个控制层，不涉及数据平面。


OpenStack 级联是“OpenStack 编排 OpenStack”。OpenStack 级联主要集中在 API 聚合，并提供租户级别的跨 OpenStack IP 地址管理、网络自动化、镜像复制/注册等。同时也为租户提供虚拟 OpenStack 体验，即使他的资源分布在多个后端 OpenStack 实例中。级联后，租户只需要访问一个 API 端点。对于租户来说，它就像一个虚拟的单个区域，多个子 OpenStack 不可见，已经被级联 OpenStack 集成和隐藏。租户可以看到多个“可用区”，资源分布在其中，每个子 OpenStack 内部都像 Amazon 那样的可用区一样工作。

用例

  • 大规模云像一个 OpenStack 实例一样工作 :

云管理员希望为租户提供一个具有一个 OpenStack api 的云，并希望该云像一个 OpenStack 实例一样工作。该云分布在多个数据中心或单个非常大规模的数据中心（例如 100k 个节点）。该云将随着容量的逐步扩展而增长，为了避免厂商锁定，需要多个厂商的 OpenStack 发行版来共同构建该云。

Cascading10.png

  • 租户级别的虚拟 OpenStack 服务，覆盖混合、联合或多个基于 OpenStack 的云:

( OpenStack 东京峰会上基于 OpenStack 级联的混合云视频：https://www.youtube.com/watch?v=XQN6jBg442o )

对于大规模云提供商，当租户访问他的云资源时，将被重定向到分配/指定给他的级联 OpenStack 的门户/API 端点，就像一个虚拟 OpenStack，它集成了他在多后端云中的资源，为他服务。通过级联 OpenStack，租户可以全局查看他的资源，例如全局配额、镜像、虚拟机、互连网络、卷、计量数据……

这些位于级联 OpenStack 后面的云可能通过 KeyStone 联合，或使用共享 KeyStone，甚至一些在 AWS 或 Azure 上构建的 OpenStack 云，或 VMWare vSphere。由于为级联开发的 AWS/Azure 驱动程序，即使混合云也可以集成到级联 OpenStack 后面。该云可以由池中的无限个 OpenStack 实例（甚至混合资源）组成。

在这种部署场景下，可以实现云中的无限可扩展性，但仍然为租户提供一致的全局视图。没有统一的级联层，多 OpenStack 云中的租户级别资源编排完全分布式（甚至地理上分布式），根本没有中心点。一个级联 OpenStack 的数据库和负载非常小，易于灾难恢复或备份。多个租户可以共享一个级联 OpenStack 以减少资源浪费，但原则是尽可能保持级联 OpenStack 的精简。

Cascading15.png

动机

多站点云集成的要求和驱动力是跨 DC / OpenStack 资源编排：全局可寻址的租户，导致全局服务。租户虚拟资源将分布在多个站点，但通过 L2/L3 网络连接。请参阅 OpenStack 多区域模式问题

  • 生态系统友好的统一多站点资源编排的开放 API

生态系统友好的开放 API：OpenStack 花了近 4 年时间来发展生态系统，OpenStack API 必须保留用于分布式但统一的多站点资源编排。

  • 多站点云需要多厂商 OpenStack 发行版、多 OpenStack 实例、多 OpenStack 版本共存

多厂商：反厂商锁定业务策略。
多实例：每个厂商都有自己的 OpenStack 解决方案发行版，不同站点使用不同的 OpenStack 实例
多版本：逐步云建设，逐步升级

  • 每个站点的 Restful 开放 API /CLI

每个站点的 OpenStack API：开放、事实上的标准 API
使云始终可用且易于管理，每个站点独立运行
每个站点的安装/升级/维护由不同的厂商或云管理员独立完成

请参阅幻灯片 使用 OpenStack 级联构建多站点和多 OpenStack 云，了解更多背景信息。

从技术角度来看，构建大规模分布式 OpenStack 云，例如，多站点云包括 100 万个虚拟机或 10 万个主机，存在很大的挑战

自然，有两种方法可以做到

1. 扩展单个单体 OpenStack 区域，但是

  • 单个 OpenStack 管理例如 100 万个虚拟机或 10 万个主机规模是一个巨大的挑战。
  • 无法获得像 EC2 的可用区那样的真实故障隔离区域，所有云都因为共享 RPC 消息总线和数据库而紧密结合。
  • 单个巨大的单体系统带来了高风险的 O&M 和故障排除，即使是最熟练的 Op 团队也很难处理 SW 滚动升级和配置更改等。
  • 异构厂商基础设施集成的时间消耗，多厂商基础设施共存是大规模云的强烈需求

2. 设置数百个具有离散 API 端点的 OpenStack 区域，但是

  • 必须购买或开发自己的云管理平台来将离散云集成到一个云中，并且 OpenStack API 生态系统也丢失了。
  • 或者，让云资源分散在孤立的岛屿上，没有任何关联……

灵感

这不是重复造轮子。OpenStack 级联解决方案的灵感来自

  • 远程集群的超visor，例如 vCenter、在 Nova 下运行的 Ironic。这使得 Nova 可以扩展到更大的规模。
  • Nova/Cinder/Neutron 的可插拔驱动程序/代理架构
  • 神奇的 FRACTAL，具有递归自相似和增长的特征。请参阅 OpenStack 级联和分形，了解更多信息。

从灵感中，得出了以下结论

  • 处理级联的 Nova/Cinder 类似于 vCenter 和 Ironic 的处理方式
  • 处理级联的 Neutron 类似于 L2 OVS 代理 / L3 DVR 代理。挑战是使跨级联 OpenStack 的 L2/L3 网络像在一个 OpenStack 中一样。


现在，级联的 OpenStack 就像一个巨大的计算节点，级联的 OpenStack 就像控制器节点。

PoC 架构

此处描述的所有信息仅用于 PoC。

有关详细的 PoC 架构设计，请参阅以下链接。


通常，Nova 将使用 KVM 或其他 hypervisor 作为计算虚拟化后端，Cinder 将使用 LVM 或其他块存储作为存储后端，Neutron 将使用 OVS 或其他作为 L2 后端，linux 路由器作为 L3 代理，等等。

OpenStack 级联的核心架构思想是将 Nova 添加为 Nova 的 hypervisor 后端，Cinder 作为 Cinder 的块存储后端，Neutron 作为 Neutron 的后端，Glance 作为 Glance 的一个镜像位置，Ceilometer 作为 Ceilometer 的存储。

Cascading12.png

OpenStack 级联包括 Nova、Cinder、Neutron、Glance 和 Ceilometer 的级联。KeyStone 将由级联和级联 OpenStack 共享的全局服务（或使用 KeyStone 联合），Heat 将消耗级联 OpenStack API。因此，不需要对 KeyStone 和 Heat 进行级联。下图是 Nova/Cinder/Neutron 级联的架构。

Cascading02.png


  • Nova-Proxy：运行在 Nova-Compute 节点上的 Nova 的 hypervisor 驱动程序。Nova proxy 使级联的 Nova 成为 Nova 的 hypervisor 后端。将 VM 操作转移到相应的级联 Nova。还负责将卷和网络附加到级联 OpenStack 中的 VM。


  • Cinder-Proxy：运行在 Cinder-Volume 节点上的 Cinder 的 Cinder-Volume 驱动程序。Cinder proxy 使 Cinder 成为 Cinder 的块存储后端。将卷操作转移到相应的级联 Cinder。


  • L2-Proxy：类似于 OVS-Agent 的角色。L2-Proxy 使级联的 Neutron 成为 Neutron 的 L2 后端。完成级联 OpenStack 中的 L2 网络，包括跨 OpenStack 网络。


  • L3-Proxy：类似于 DVR L3-Agent 的角色。L3-Proxy 使级联的 Neutron 成为 Neutron 的 L3 后端。完成级联 OpenStack 中的 L3 网络，包括跨 OpenStack 网络。


  • FW-Proxy：类似于 FWaaS-Agent 的角色。FW-Proxy 使级联的 Neutron 成为 Neutron 的 FWaaS 后端。


  • LB-Proxy：类似于 LBaaS-Agent 的角色。LB-Proxy 使级联的 Neutron 成为 Neutron 的 LBaaS 后端。


  • VPN-Proxy：类似于 VPNaaS-Agent 的角色。VPN-Proxy 使级联的 Neutron 成为 Neutron 的 VPNaaS 后端。



对于 Glance，不一定需要级联。这取决于后端存储和部署决策。两种方法都可以使级联的 Glance 成为一个镜像位置

  1. 第一种方法是在上传镜像数据或修补镜像位置或创建快照时复制镜像，这样可以获得更好的最终用户体验，缩短 VM 启动时间，但使用的技术更复杂。
  2. 第二种方法是在镜像第一次在相应的级联 OpenStack 中使用时才复制镜像数据。这样第一次 VM 启动完成任务需要更长的时间，但它更简单和健壮。
  3. 第三种方法只是在级联 Glance 中注册已经存在的镜像的位置


对于 Ceilometer，必须引入级联解决方案。将产生大量的卷数据在 Ceilometer 内部，不可能使用共享的 Ceilometer 来处理所有站点。

Cascading03.png

  • Repli-Manager：在级联和策略确定的级联 OpenStack 之间复制镜像。仅当使用镜像同步时才需要上传镜像数据或修补镜像位置或创建快照。
  • Ceilometer-Proxy：将请求转移到目标 Ceilometer 或从多个 Ceilometer 收集信息。

对最终用户的价值

  • 租户对多云中的资源具有全局视图

租户的资源 VM、卷可能分布在多个使用共享 KeyStone 或 KeyStone 联合的 OpenStack 中，并且这些资源通过 L2/L3 网络以及 FW、LB、VPN 等高级服务互连。租户的分布式资源可以通过级联 OpenStack 进行管理，就像租户拥有一个虚拟 OpenStack 一样，租户可以全局查看他的资源，例如镜像、计量数据、VM/卷/网络等。租户还可以通过级联 OpenStack 拥有全局配额控制和资源利用率。

  • 租户级别的全局 IP 地址管理。

级联 OpenStack 可以在多个级联 OpenStack 中充当租户的全局 IP 地址管理。

  • 虚拟机/卷迁移/vApp 迁移从一个数据中心到另一个数据中心

借助 OpenStack 级联，从一个 DC 到另一个 DC 的 VM/Volume 迁移是可行的。请参阅博客 通过 OpenStack 级联进行跨 DC 应用程序迁移

  • 跨不同物理数据中心的高可用性应用程序。

借助跨数据中心的覆盖虚拟 L2/L3 网络和镜像同步功能，在分布式云中很容易实现应用程序备份/灾难恢复/负载平衡。

对云管理员的价值

有关更多详细信息，请参阅“OpenStack 级联架构”部分中链接的文档。该架构的主要优势在此列出

  1. 级联 OpenStack 通过标准的 OpenStack API 将许多子 OpenStack 云聚合到一个云中，并通过级联 OpenStack 为租户暴露一个 OpenStack API 端点。
  2. 如果一个级联的 OpenStack 失败，云的其他部分仍然可以工作和访问。这使得一个级联的 OpenStack 可以充当类似 Amazon 的可用区。如果级联 OpenStack 失败，所有级联 OpenStack 仍然可以通过 OpenStack API 独立管理和使用。在第一阶段，为了考虑级联和级联 OpenStack 之间的一致性，不允许进行资源配置。在第二阶段，在一致性问题解决后，即使级联 OpenStack 失败，也可以允许进行资源配置。
  3. 级联 OpenStack 通过标准的 OpenStack API 管理级联 OpenStack。OpenStack API 是一种具有向后兼容性和并行多版本 API 的 RESTful API。因此，在一个大型云中，可以使用多厂商/多版本的 OpenStack。
  4. 每个级联 OpenStack 和级联 OpenStack 都可以作为独立的 OpenStack 进行独立管理。因此，升级或运维可以在可用区粒度上单独进行。
  5. 依赖于级联 OpenStack 管理的标准 OpenStack API，带有内置 OpenStack 发行版的新的厂商物理资源可以通过即插即用模式集成到云中，就像 USB 设备插入 PC 一样。这种优势使 OpenStack API 成为云时代中软件定义的“PCI”总线。
  6. 可扩展性不仅存在于一个级联 OpenStack 中，还存在于分布在许多数据中心的多个厂商的级联 OpenStack 和联合 OpenStack 中。由于 OpenStack API 是一种 RESTful API，因此一个级联 OpenStack 可以管理分布在 WAN 或 LAN 上的多个 OpenStack，这是可行的。

概念验证

PoC 使我们相信 OpenStack 级联解决方案是可行的，请参阅 StackForge 中的 Tricircle PoC：https://github.com/stackforge/tricircle/tree/poc，或 https://github.com/stackforge/tricircle/tree/stable/fortest

PoC 的主要联系人是黄朝义 ( joehuang@huawei.com )

PoC 可扩展性测试报告

请参阅：OpenStack 级联解决方案支持 100 个数据中心中 100 万个 VM 的测试报告

PoC 在线演示视频

目前只有在线演示视频可用，很难为我们设置一个全球可访问的在线实验室。

YouTube: https://www.youtube.com/watch?v=OSU6PYRz5qY

优酷 (低质量，适用于无法访问 YouTube 的用户)：http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html

Vimeo: http://vimeo.com/107453159

与 Tricircle 的关系

在级联的 PoC 之后，启动了一个名为 Tricircle ( https://wiki.openstack.org/wiki/Tricircle , https://github.com/openstack/tricircle ) 的 OpenStack 项目，设计将根据经验教训进行改进，并且项目将在 OpenStack 大帐篷指南下运行。

邮件列表

使用 OpenStack 开发列表，请在邮件标题中包含 [openstack-dev][tricircle]。

PoC 期间的讨论

最后更新

--joehuang (讨论) 2015年7月6日 星期二 02:37 (UTC)

检索自 "https://wiki.openstack.org/w/index.php?title=OpenStack_cascading_solution&oldid=151271"