跳转到： 导航, 搜索

Trio2o

Trio2o 的目标是为多个 OpenStack 云提供 API 网关，这些云可以位于同一站点、多个站点或混合云中，从而充当单个 OpenStack 云。

用例

对于多个 OpenStack 实例的单个端点需求取决于云操作员的偏好。有些操作员可能更喜欢单个端点，但有些则不然。在云中存在多个 OpenStack 实例的情况有很多。

大规模云

与 Amazon 相比，OpenStack 的可扩展性仍然不够好。一个 Amazon AZ 可以支持超过 50000 台服务器（http://www.slideshare.net/AmazonWebServices/spot301-aws-innovation-at-scale-aws-reinvent-2014）。

Cells 是 Nova 可扩展性的一个很好的增强，但 Cells 的缺点是：1) 使用 RPC 进行数据中心间通信会带来数据中心间故障排除和维护的困难，以及一些关键的运营问题。没有 CLI 或 restful API 或其他工具可以直接管理子单元。如果 API 单元和子单元之间的链接断开，则远程边缘云中的子单元将无法管理，无论本地还是远程。 2). 站点间 RPC 通信的安全管理挑战。请参阅幻灯片 [1] 中的挑战 3：通过互联网保护 OpenStack，需要打开防火墙中的 500 多个通道才能使其工作 – 包括用于 CLI 的 VNC 和 SSH 端口。在边缘云中使用 Cells 中的 RPC 将面临相同的安全挑战。3) 只有 nova 支持 cells。但不仅仅是 Nova 需要支持边缘云，Neutron、Cinder 也应该考虑在内。Neutron 如何支持边缘云中的服务功能链？使用 RPC？如何解决上述挑战？Cinder 呢？ 4). 使用 RPC 进行数百个边缘云的生产集成是一个具有挑战性的想法，这些边缘云可能来自多个供应商，硬件/软件或两者兼而有之，这是基本要求。

从生产大规模公共云的经验来看，大规模云可以通过逐步扩展容量（AZ 内和 AZ 间）来构建。容量扩展的挑战在于如何进行容量规划

  • Nova-API 服务器的数量…
  • Cinder-API 服务器的数量…
  • Neutron-API 服务器的数量…
  • 调度器的数量…
  • Conductor 的数量…
  • 物理交换机的规格…
  • Image 存储空间的大小…
  • 管理平面带宽的大小…
  • 数据平面带宽的大小…
  • 机架空间的预留…
  • 网络插槽的预留…
  • …

每当你向云中添加新机器时，你必须估计、计算、监控、模拟、测试、在线灰度扩展控制器节点和网络节点……你无法在所有规模下进行测试和验证。

扩展大规模云的可行方法是添加一些已经测试过的构建块。这意味着我们更喜欢通过逐个添加经过测试的 OpenStack 实例（包括控制器和计算节点）来构建大规模云，但更不喜欢无条件地扩大单个 OpenStack 实例的容量。这样可以将云的构建置于控制之下。

通过逐个添加经过测试的 OpenStack 实例来构建大规模云，但从最终用户和 PaaS 的角度来看，他们仍然希望使用 OpenStack API 来使用已经开发的 CLI、SDK、Portal、PaaS、Heat、Maganum、Murano 等。这种构建大规模公共云的方式也带来了一些新的 OpenStack 云需求，这与大规模分布式边缘云非常相似

  • 大规模云的单个端点
  • 分布式配额管理
  • 租户的全局资源视图
  • 租户级别的 Volume/VM 迁移/备份
  • 多 DC image 导入/克隆/导出
  • ...


大规模分布式边缘云

现在，在边缘数据中心构建大规模分布式边缘云，计算和存储靠近最终用户，这对于企业应用、NFV 服务和个人服务来说正在兴起。

企业应用

一些企业也发现应用程序在远程集中式云中运行存在问题，例如对于视频编辑、3D 建模应用程序和 IoT 服务等，这些应用程序对带宽和延迟敏感。

边缘云提供的带宽和低延迟对于视频编辑、3D 建模、AR/VR、IoT 服务等企业级应用程序至关重要

对于企业而言，大多数员工将在不同的分支机构工作，并访问附近的边缘云，并且来自不同分支机构的员工之间的协作导致对跨边缘云功能的需求，例如数据分发和迁移。

NFV 和边缘云服务

NFV（网络功能虚拟化）将提供更灵活和更好的定制网络能力，例如动态定制网络带宽管理，并有助于将计算和存储移近最终用户。从最终用户到存储和计算的最短路径，上行速度可以更大，并尽快终止带宽消耗，这肯定会带来更好的用户体验，并改变内容生成和存储的方式：实时、所有数据都在云中。

例如，用户/企业可以动态请求高带宽/存储需求，以暂时将 HD 视频/AR/VR 数据流式传输到云端，流式传输完成后，请求更多的计算资源进行后期处理，并将视频重新分发到其他站点。当用户想要将应用程序和数据从一个边缘云移动/重新分发到另一个边缘云时，应该能够动态请求由 NFV 管理的跨边缘云带宽。

个人服务

当前的互联网擅长处理下行服务。所有内容都存储在远程集中式数据中心，并在一定程度上通过 CDN 加速访问。

随着越来越多的用户生成上传/流式传输到云端和网站的内容和数据，这些内容和数据仍然必须上传/流式传输到一些集中式数据中心，路径很长，带宽有限且速度慢。例如，同时上传/流式传输 HD/2k/4k 视频对于每个用户来说非常慢。对于图片或视频，必须以牺牲质量为代价上传，速度慢，使用云作为用户数据的第一个存储选择尚未成为选择，目前主要用于备份，以及对于非时间/延迟敏感的数据。一些捕获并以牺牲质量为代价存储的视频甚至导致难以提供犯罪证据或其他目的。最后一英里的网络访问（固定或移动）足够宽，主要的障碍是 MAN（城域网）和骨干网和 WAN 中的带宽有限且昂贵。从最终用户/终端到本地边缘云的实时视频/数据上传/流式传输是一个非常有吸引力的云服务。

需求

新兴的大规模分布式边缘云不仅仅是一些云孤岛，还需要一些新的需求

  • 在特定部署场景中，大量小型边缘云的单个端点
  • 租户级别的 Volume/VM/对象存储备份/迁移/分发
  • 分布式镜像管理
  • 分布式配额管理
  • ...

OpenStack API 启用的混合云

请参阅 https://wiki.openstack.org/wiki/Jacket
混合云的单个端点有强烈需求。

详细的使用案例可以在此演示文稿中找到：https://docs.google.com/presentation/d/16laTyn4ra-446v4p0kwMnpgHqwzMsz1r6QeiSI2Kq2M/

更多技术用例可以在 Tricircle 大帐篷项目申请中使用的通信材料中找到，在某些部署中也有对单个端点需求：https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/edit?usp=sharing

概述

Trio2o 的目标是为多个 OpenStack 云提供 API 网关，这些云可以位于同一站点、多个站点或混合云中，从而充当单个 OpenStack 云。

Trio2o 和这些管理的 OpenStack 实例将使用共享 KeyStone（具有集中式或分布式部署）或联合 KeyStone 进行身份管理。Trio2o 在 KeyStone 中向最终用户呈现一个大的区域。每个 OpenStack 实例称为 pod 是 Trio2o 在 KeyStone 中的子区域，通常对最终用户不可见。

Trio2o 充当 OpenStack API 网关，可以处理 OpenStack API 调用，在 API 调用处理期间根据需要调度一个合适的 OpenStack 实例，并将 API 调用转发到适当的 OpenStack 实例。

最终用户可以看到可用区 (AZ) 并使用 AZ 通过 Trio2o 预置 VM、Volume。一个 AZ 可以包含许多 OpenStack 实例，Trio2o 可以在一个 AZ 内为租户调度和绑定 OpenStack 实例。租户的资源可以自动绑定到多个特定的底层 OpenStack 实例，这些实例位于一个或多个 AZ 中。

Trio2o 源自旧的 Tricircle，专用于 API 网关。

Trio2o 可以扩展以支持更强大的功能，例如支持将 Trio2o 实例虚拟拆分为多个微实例，这可以使用户对租户和服务的粒度更细。Trio2o 还支持基于 OpenStack 的混合云。

架构

现在，Trio2o 被设计为独立的 API 网关服务，与 OpenStack 现有的服务（如 Nova、Cinder）解耦。设计蓝图正在不断改进中，请参见 https://docs.google.com/document/d/1cmIUsClw964hJxuwj3ild87rcHL8JLC-c7T-DUQzd4k/


Trio2o architecture design


共享 KeyStone（集中式或分布式部署）或联合 KeyStone 可用于 Trio2o 和管理的 OpenStack 实例的身份管理。Trio2o 在 KeyStone 中向最终用户呈现一个大的区域。每个 OpenStack 实例称为 pod 是 Trio2o 在 KeyStone 中的子区域，通常对最终用户不可见。

  • Nova API-GW
  1. 一个独立的 Web 服务，用于接收所有 nova API 请求，并根据可用区（在创建期间）或 VM 的 uuid（在操作和查询期间）将请求路由到适当的底层 OpenStack 实例。如果一个可用区中有多个 OpenStack 实例，则调度一个并将其转发到适当的 OpenStack 实例，并建立租户 ID 和 OpenStack 实例之间的绑定关系。
  2. 作为无状态服务运行，并且可以在多个主机上分布式运行。
  • Cinder API-GW
  1. 一个独立的 Web 服务，用于接收所有 cinder API 请求，并根据可用区（在创建期间）或资源 ID（如 volume/backup/snapshot uuid）（在操作和查询期间）将请求路由到适当的底层 OpenStack 实例。如果一个可用区中有多个 OpenStack 实例，则调度一个 OpenStack 实例并将其转发到适当的 OpenStack 实例，并建立租户 ID 和 OpenStack 实例之间的绑定关系。
  2. Cinder APIGW 和 Nova APIGW 将确保同一 VM 的 volume 位于同一 OpenStack 实例中。
  3. 作为无状态服务运行，并且可以在多个主机上分布式运行。
  • Admin API
  1. 管理站点（底层 OpenStack 实例）和可用区映射。
  2. 检索对象 uuid 路由。
  3. 公开用于维护的 API。
  • XJob
  1. 接收并处理来自 Nova API-GW、Cinder API-GW、Admin API 的跨 OpenStack 功能和其他异步作业。
  2. Admin API、Nova API-GW、Cinder API-GW 都可以通过 RPC API 通过消息总线将异步作业发送到 XJob。
  • 数据库
  1. Tricircle 有自己的数据库来存储 pod、pod 绑定、作业、资源路由表。

对于 Glance 部署，有几种选择

  • 共享 Glance，如果所有 OpenStack 实例都位于高带宽、低延迟站点内。
  • 共享 Glance 与分布式后端，如果 OpenStack 实例位于多个站点中。
  • 分布式 Glance 部署，Glance 服务分布式部署在多个站点，并具有分布式后端
  • 单独的 Glance 部署，每个站点都安装了单独的 Glance 实例和后端，不需要跨站点镜像共享。

值

开发 Trio2o 开源项目的动机

  • OpenStack API 生态系统保留，从 CLI、SDK 到 Heat、Murano、Magum 等，所有这些都可以无缝重用。
  • 支持大规模云中的模块化容量扩展。
  • 跨 OpenStack 实例的租户级别配额控制。
  • 跨 OpenStack 实例的全局资源使用情况视图。
  • 跨 OpenStack 实例的租户级别 KeyPair 管理。
  • 由于租户级别的 L2/L3 网络，租户的数据在 OpenStack 实例之间的移动。
  • ...

安装和使用

请参阅 https://github.com/openstack/trio2o 中的安装指南，了解使用 devstack 设置单节点/双节点的方法。

资源

Trio2o 旨在使用与其他 OpenStack 项目相同的工具进行提交和审查。因此，我们遵循 OpenStack 开发工作流程。新贡献者应遵循 入门步骤，因为需要 Launchpad ID 和已签名的贡献者许可才能添加新条目。

如何阅读源代码

要阅读源代码，如果遵循此蓝图会更容易

实现无状态架构：https://blueprints.launchpad.net/tricircle/+spec/implement-stateless

此蓝图旨在从头构建 Tricircle，同时也是 Trio2o 项目的代码基础。

历史记录

问：Trio2o、Tricircle 和 OpenStack Cascading 之间有什么区别？

OpenStack Cascading 主要是一个在 2014 年底和 2015 年初进行的 PoC（概念验证）中使用的解决方案，旨在测试多个 OpenStack 实例可以部署在多个地理位置分散的站点上，并由 OpenStack API 层管理，该层基于 OpenStack 服务。PoC 成功实施后，团队计划将核心思想贡献给社区。

Tricircle 正是基于这个想法诞生的。与 PoC 中 OpenStack cascading 解决方案的 V1 实现不同，后者包含大量的特性增强和管道，Tricircle 在早期阶段尝试构建一种干净的架构，这种架构具有可扩展性、可插拔性和可重用性，它包括 OpenStack API 网关和网络自动化功能。

2016 年 9 月，根据 Tricircle 大本营应用 Trio2o 的反馈，Trio2o 旨在提供 API 网关功能，从 Tricircle 中分离出来。这使得 Tricircle 专注于跨 Neutron 的网络自动化。

Tricircle：专用于在多区域 OpenStack 部署中进行跨 Neutron 网络自动化，可以独立运行或与 Trio2o 一起运行。

Trio2o：专用于为需要在多区域 OpenStack 部署中提供单个 Nova/Cinder API 端点的人们提供 API 网关，可以独立运行或与 Tricircle 一起运行。

Tricircle 在拆分之前的 wiki 链接：https://wiki.openstack.org/wiki/tricircle_before_splitting

问：源代码在哪里？
Trio2o 源代码是从 Tricircle 分叉并进行清理后的。

https://etherpad.openstack.org/p/Trio2oCleaning

待办事项

待办事项列表在 etherpad 中：https://etherpad.openstack.org/p/Trio2oToDo

从 Tricircle 同步 Nova API-GW/Cinder API-GW 部分的补丁：http://lists.openstack.org/pipermail/openstack-dev/2016-December/108552.html

会议记录

所有会议日志和记录都可以在此处找到
2016：http://eavesdrop.openstack.org/meetings/trio2o/2016/

团队成员

在 IRC 频道中联系团队成员：#openstack-trio2o

当前活跃参与者

Joe Huang，华为

Khayam Gondal，戴尔

Shinobu Kinjo，RedHat

Ge Li，中国银联

Vega Cai，华为

Pengfei Shi，OMNI Lab

Bean Zhang，OMNI Lab

Yipei Niu，华中科技大学

Ronghui Cao，湖南大学

Xiongqiu Long，湖南大学

Zhuo Tang，湖南大学

Liuzyu，湖南大学

Jiawei He，湖南大学

KunKun Liu，湖南大学

Yangkai Shi，湖南大学

Yuquan Yue，湖南大学

Howard Huang，华为

从 "https://wiki.openstack.org/w/index.php?title=Trio2o&oldid=151257" 检索