Tricircle

Tricircle 旨在为多区域 OpenStack 部署中的 Neutron 提供网络自动化。

用例

要理解 Tricircle 项目的动机，我们应该理解最终用户用例，这将帮助您理解这个项目，请参考演示材料： https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/

0. 电信应用云级别冗余，OPNFV 北京峰会

共享网络以支持跨 OpenStack 多区域部署的 VNF 高可用性。此幻灯片在 2017 年 OPNFV 北京峰会上展示。幻灯片： https://docs.google.com/presentation/d/1WBdra-ZaiB-K8_m3Pv76o_jhylEqJXTTxzEZ-cu8u2A/ 视频： https://www.youtube.com/watch?v=tbcc7-eZnkY OPNFV Summit vIMS 多站点演示(Youtube)： https://www.youtube.com/watch?v=zS0wwPHmDWs 视频会议跨多个 OpenStack 云的高可用性(Youtube)： https://www.youtube.com/watch?v=nK1nWnH45gI

1. 应用在高可用云上运行

在电信和其他行业（例如，MySQL Galera 集群）中，应用程序通常被设计为主动-主动、主动-被动或 N 对 1 节点配置。因为这些应用程序需要尽可能地可用。一旦这些应用程序计划迁移到云基础设施，主动实例需要首先部署到一个 OpenStack 实例中。之后，被动或主动实例将被部署到另一个（其他）OpenStack 实例中，以便在需要时实现 99.999% 的可用性。

之所以需要这种部署方式，是因为通常云系统只能实现 99.99% 的可用性。[1] [2]

为了实现所需的高可用性，需要考虑跨 Neutron 的网络架构设计（尤其是第二层和第三层），用于应用程序状态复制或心跳检测。

上图显示了一个使用 Galera DB 集群作为后端的应用程序，这些应用程序在多个 OpenStack 实例中地理分布。

[1] https://aws.amazon.com/cn/ec2/sla/
[2] https://news.ycombinator.com/item?id=2470298

2. 双 ISP 互联网链路负载均衡

在单独的 OpenStack 实例中部署应用程序，并使用双 ISP 进行互联网链路冗余、负载均衡、东西向流量隔离以进行数据/状态复制是必需的。

3. 东西向流量隔离

在金融行业，将部署多个 OpenStack 实例，一些 OpenStack 实例将放置在 DMZ 区域，其他实例放置在信任区域，以便可以将应用程序或应用程序的一部分放置在不同的安全级别区域。即使租户的资源被配置在不同的 OpenStack 实例中，租户资源之间的东西向流量也应被隔离。

带宽敏感、高负载的应用，如 CAD 建模，为了获得更好的用户体验，需要靠近最终用户的分布式边缘站点，将在边缘站点部署多个 OpenStack 实例，但租户资源之间的东西向通信也需要隔离。

在 OpenStack 巴塞罗那峰会的 ops 会议中也可以找到类似的需求“控制平面设计（多区域）”第 25~26 行，47~50 行： https://etherpad.openstack.org/p/BCN-ops-control-plane-design

4. NFV 区域跨 Neutron L2 网络

在 NFV（网络功能虚拟化）领域，路由器、NAT、LB 等网络功能将被虚拟化。Tricircle 提供的跨 Neutron L2 网络能力，如 IP 地址空间管理、IP 分配和 L2 网络段全局管理，可以帮助 VNFs（虚拟化网络功能）跨站点互连。例如，vRouter1 在站点 1 中，但 vRouter2 在站点 2 中，这两个 VNF 可以在跨站点的同一个 L2 网络中。

5. 云容量扩展

当创建一个 OpenStack 云并对其配置了许多资源时，其中一个 OpenStack 部署的容量可能不足。需要添加一个新的 OpenStack 部署到该云中。但租户仍然希望将虚拟机添加到现有网络。他们不想添加新的网络、路由器或任何其他必需的资源。

架构

现在，Tricircle 致力于为多区域 OpenStack 部署中的 Neutron 提供网络自动化。设计蓝图正在不断改进中，请参阅 https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/。

从控制平面视图（云管理视图）来看，Tricircle 旨在使多区域 OpenStack 云中的 Neutron(s) 像一个集群一样工作，并能够创建跨多个 OpenStack 云的全局网络/路由器等抽象网络资源。从数据平面视图（最终用户资源视图）来看，所有虚拟机（也可以是裸机服务器或容器）都配置在不同的云中，但可以通过全局抽象网络资源互连，当然，具有租户级别的隔离。

软件设计如下

共享 KeyStone（集中式或分布式部署）或联合 KeyStone 可用于 Tricrcle 和多个 OpenStack 实例的身份管理。

Tricircle Local Neutron Plugin

它在与 OVN/Dragonflow Neutron 插件一样的方式下，在 Neutron 服务器的同一进程中运行。
Tricircle Local Neutron Plugin 用于跨 Neutron 网络自动化的触发。它是真实核心插件和 Neutron API 服务器之间的一个垫层
在 Tricircle 上下文中，Tricircle Local Neutron Plugin 可以简称为“本地插件”。
安装了 Tricircle Local Neutron Plugin 的 Neutron 服务器也称为“本地 Neutron”或“本地 Neutron 服务器”。与中央 Neutron 协同工作的 Nova/Cinder 也可以称为本地 Nova/本地 Cinder。

Tricircle Central Neutron Plugin

它在与 OVN/Dragonflow Neutron 插件一样的方式下，在 Neutron 服务器的同一进程中运行。
Tricircle Central Neutron Plugin 用于跨多个 OpenStack 实例的租户级别 L2/L3 网络自动化。
在 Tricircle 上下文中，Tricircle Central Neutron Plugin 可以简称为“中央插件”。
安装了 Tricircle Central Neutron Plugin 的 Neutron 服务器也称为“中央 Neutron”或“中央 Neutron 服务器”。

Admin API

管理 OpenStack 实例和可用区之间的映射。
检索对象 uuid 路由。
公开用于维护的 API。

XJob

接收并处理来自 Admin API 或 Tricircle Central Neutron Plugin 的跨 OpenStack 功能和其他异步作业。
例如，当首次为项目启动实例时，路由器、安全组规则、FIP 和其他资源可能尚未在底层的 OpenStack 实例中创建，这些资源可以异步创建，以加速首次实例启动请求的响应速度。与网络、子网、安全组资源不同，它们必须在实例启动之前创建。
Admin API、Tricircle Central Neutron 插件可以通过提供 XJob 的 RPC API 通过消息总线将异步作业发送到 XJob。

数据库

Tricircle 拥有自己的数据库，用于存储 Tricircle Central Neutron 插件、Admin API 和 XJob 的 Pod、作业和资源路由表。
Tricircle Central Neutron Plugin 还会重用中央 Neutron 服务器的数据库来对租户的资源（如 IP/MAC/网络/路由器）进行全局管理。
Tricircle Local Neutron Plugin 是真实核心插件和 Neutron API 服务器之间的垫层，因此 Neutron DB 仍然存在于 Neutron API 服务器和真实核心插件中。

对于 Glance 部署，有几种选择