Tricircle 在拆分之前
Tricircle 提供了一个 OpenStack API 网关和网络自动化,允许管理多个 OpenStack 实例,这些实例可能位于单个站点、多个站点或混合云中,从而将它们作为一个单一的 OpenStack 云进行管理
目录
用例
大规模分布式边缘云
目前正在边缘数据中心构建大规模分布式边缘云,这些数据中心拥有靠近最终用户的计算和存储能力,用于企业应用、NFV 服务和个人服务。
企业应用
一些企业也发现应用程序在远程集中式云中运行存在问题,例如视频编辑、3D 建模应用和物联网服务等,这些应用对带宽和延迟敏感。
边缘云提供的的高带宽和低延迟对于视频编辑、3D 建模、物联网服务等企业级应用至关重要
对于企业而言,大多数员工将在不同的分支机构工作,并访问附近的边缘云,并且来自不同分支机构的员工之间的协作导致了对跨边缘云功能的需要,例如租户级别的网络、数据分发和迁移。
NFV 和边缘云服务
NFV(网络功能虚拟化)将提供更灵活和更好的定制网络能力,例如动态定制的网络带宽管理,并有助于将计算和存储移近最终用户。从最终用户到存储和计算的最短路径可以使上行速度更快,并尽快终止带宽消耗,这肯定会带来更好的用户体验,并改变内容生成和存储的方式:实时、所有数据都在云端。
例如,用户/企业可以动态请求用于将高清视频/AR/VR 数据流式传输到云端的高带宽/存储需求,流式传输完成后,请求更多计算资源进行后期处理,并将视频重新分发到其他站点。当用户想要将应用程序和数据从一个边缘云移动/重新分发到另一个边缘云时,应该能够动态请求由 NFV 管理的跨边缘云带宽。
对于 VNF(电信虚拟化应用),分布式设计的 VNF 将放置在多个边缘数据中心以提高可靠性/可用性。为了提供此支持,通常需要在应用程序实例之间进行状态复制(直接或通过复制的数据库服务,或通过私有设计的消息格式),需要跨数据中心的租户级别隔离的网络平面用于应用程序状态复制。
个人服务
当前的互联网擅长处理下行服务。所有内容都存储在远程集中式数据中心,并在一定程度上通过 CDN 加速访问。
随着越来越多的用户生成上传/流式传输到云端和网站的内容,这些内容和数据仍然必须上传/流式传输到一些集中式数据中心,路径漫长且带宽有限且速度慢。例如,每个用户同时上传/流式传输高清/2k/4k 视频非常慢。对于图片或视频,它们必须以质量损失和缓慢的方式上传,使用云作为用户数据的第一个存储选择尚未成为选择,目前主要用于备份和非时间/延迟敏感数据。一些捕获并以质量损失存储的视频甚至导致难以提供犯罪证据或其他目的。最后一英里的网络访问(固定或移动)足够宽,主要的障碍是 MAN(城域网)和骨干网以及 WAN 中的带宽有限且昂贵。从最终用户/终端到本地边缘云的实时视频/数据上传/流式传输是非常有吸引力的云服务。
从家庭或个人角度来看,应用程序/存储在边缘数据中心之间移动或分发也是必需的。例如,我在夏威夷旅行时拍摄视频时,所有视频都将存储和处理在当地,但我想在返回中国后将处理后的视频移动到中国深圳。但在深圳,我想通过流媒体服务与上海北京的朋友分享视频,因此数据和流媒体服务也可以在深圳/上海/北京构建。通过 NFV 边缘云可以帮助动态增加带宽和应用程序/数据移动/复制。
需求
新兴的大规模分布式边缘云不仅仅是一些独立的云,还需要一些新的需求
- 跨数据中心的租户级别 L2/L3 网络,用于隔离租户的 E-W 流量
- 租户级别的 Volume/VM/对象存储备份/迁移/分发
- 分布式镜像管理
- 分布式配额管理
- ...
大规模云
与亚马逊相比,OpenStack 的可扩展性仍然不够好。一个亚马逊 AZ 可以支持 >50000 台服务器 (http://www.slideshare.net/AmazonWebServices/spot301-aws-innovation-at-scale-aws-reinvent-2014)。
Cells 是 Nova 可扩展性的一个很好的增强,但 Cells 的缺点是:1) 只有 nova 支持 cells。2) 使用 RPC 进行数据中心间通信会带来数据中心间故障排除和维护的困难,没有 CLI 或其他工具可以直接管理子 cell。如果 API cell 和子 cell 之间的链接断开,则子 cell 将无法管理。
从生产大规模公共云的经验来看,大规模云可以通过逐步扩展容量(AZ 内和 AZ 间)来构建。扩展容量的挑战在于如何进行尺寸调整
- Nova-API 服务器的数量…
- Cinder-API 服务器的数量…
- Neutron-API 服务器的数量…
- 调度器的数量…
- Conductor 的数量…
- 物理交换机的规格…
- Image 存储的大小…
- 管理平面带宽的大小…
- 数据平面带宽的大小…
- 机架空间的预留…
- 网络插槽的预留…
- …
您必须估计、计算、监控、模拟、测试、在线灰度扩展控制器节点和网络节点…每当您向云中添加新机器时。困难在于您无法在所有尺寸下进行测试和验证。
扩展一个大规模云的可行方法是添加一些经过测试的构建块。这意味着我们更愿意通过逐个添加经过测试的 OpenStack 实例(包括控制器和计算节点)来构建大规模公共云,但更不愿意无条件地扩大单个 OpenStack 实例的容量。这样可以将云的构建置于控制之下。
通过逐个添加经过测试的 OpenStack 实例来构建大规模云,但租户的 VM 可能需要添加到同一个网络中,即使您添加了一个新的 OpenStack 构建,或者网络将被添加到同一个路由器中,即使这些网络位于不同的 OpenStack 构建块中。但从最终用户和 PaaS 的角度来看,他们仍然希望使用 OpenStack API 来开发 CLI、SDK、Portal、PaaS、Heat、Maganum、Murano 等。构建大规模公共云的这种方式也为 OpenStack 基于云带来了新的需求,这与大规模分布式边缘云非常相似
- 跨 OpenStack 实例的租户级别 L2/L3 网络,用于隔离租户的 E-W 流量
- 分布式配额管理
- 租户的全局资源视图
- 租户级别的 Volume/VM 迁移/备份
- 多数据中心镜像导入/克隆/导出
- ...
OpenStack API 启用的混合云
请参阅 https://wiki.openstack.org/wiki/Jacket
详细的使用案例可以在此演示文稿中找到:https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit?usp=sharing
更多技术使用案例可以在 Tricircle 大帐篷项目申请中使用的通信材料中找到:https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/edit?usp=sharing
它还可以满足多个工作组的需求:Telco WG 文档、大型部署团队使用案例和 OPNFV 多站点使用案例
概述
Tricircle 提供了一个 OpenStack API 网关和网络自动化,允许管理多个 OpenStack 实例,这些实例可能位于单个站点、多个站点或混合云中,从而将它们作为一个单一的 OpenStack 云进行管理。
Tricircle 和这些管理的 OpenStack 实例将使用共享的 KeyStone(具有集中式或分布式部署)或联合的 KeyStone 进行身份管理。Tricircle 在 KeyStone 中向最终用户呈现一个大的区域。每个 OpenStack 实例称为 pod,是 KeyStone 中 Tricircle 的子区域,通常对最终用户不可见。
Tricircle 作为 OpenStack API 网关,可以处理 OpenStack API 调用,在 API 调用处理期间根据需要调度一个合适的 OpenStack 实例,将 API 调用转发到适当的 OpenStack 实例,并自动处理跨 OpenStack 实例的租户级别 L2/L3 网络,以便位于底层 OpenStack 实例中的租户的 VM 可以通过 L2 或 L3 进行通信。
最终用户可以看到可用区 (AZ) 并使用 AZ 来配置 VM、Volume 甚至 Network 通过 Tricircle。一个 AZ 可以包含许多 OpenStack 实例,Tricircle 可以在一个 AZ 内为租户调度和绑定 OpenStack 实例。租户的资源可以自动绑定到多个特定的底层 OpenStack 实例,这些实例位于一个或多个 AZ 中。
Tricircle 是 OpenStack 级联解决方案的正式开源项目(https://wiki.openstack.org/wiki/OpenStack_cascading_solution),但具有增强和解耦的设计。
Tricircle 可以扩展以支持更强大的功能,例如支持将 Tricircle 实例虚拟拆分为多个微实例,这可以使用户对租户和服务的粒度控制更加精细。Tricircle 还支持基于 OpenStack 的混合云。
架构
现在,Tricircle 被设计为独立服务,与 OpenStack 现有的服务(如 Nova、Cinder、Neutron)解耦。设计蓝图正在不断改进中,请参阅 https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit?usp=sharing
共享的 KeyStone(集中式或分布式部署)或联合的 KeyStone 可用于 Tricircle 和管理的 OpenStack 实例的身份管理。Tricircle 在 KeyStone 中向最终用户呈现一个大的区域。每个 OpenStack 实例称为 pod,是 KeyStone 中 Tricircle 的子区域,通常对最终用户不可见。
- Nova API-GW
- 一个独立的 Web 服务,用于接收所有 nova API 请求,并根据可用区(创建期间)或 VM 的 uuid(操作和查询期间)将请求路由到适当的底层 OpenStack 实例。如果一个可用区中有多个 OpenStack 实例,则调度一个并将其转发到适当的 OpenStack 实例,并建立租户 ID 和 OpenStack 实例之间的绑定关系。
- Nova APIGW 是触发网络自动化的功能,当正在配置新的 VM 时。
- 作为无状态服务运行,并且可以在多个主机中分布式运行。
- Cinder API-GW
- 一个独立的 Web 服务,用于接收所有 cinder API 请求,并根据可用区(创建期间)或资源 ID(如 volume/backup/snapshot uuid)(操作和查询期间)将请求路由到适当的底层 OpenStack 实例。如果一个可用区中有多个 OpenStack 实例,则调度一个 OpenStack 实例并将其转发到适当的 OpenStack 实例,并建立租户 ID 和 OpenStack 实例之间的绑定关系。
- Cinder APIGW 和 Nova APIGW 将确保同一 VM 的 volume 位于同一 OpenStack 实例中。
- 作为无状态服务运行,并且可以在多个主机中分布式运行。
- Neutron API Server
- Neutron API Server 从 Neutron 重用,用于接收和处理 Neutron API 请求。
- Neutron Tricircle 插件。它在 Neutron API 服务器的同一进程下运行,就像 OVN Neutron 插件一样。Tricircle 插件用于跨多个 OpenStack 实例的租户级别 L2/L3 网络自动化。它将使用驱动程序接口来调用底层 OpenStack Neutron API 和 L2GW API(如果需要),特别是对于跨 OpenStack 混合 VLAN / VxLAN L2 网络。
- Admin API
- 管理站点(底层 OpenStack 实例)和可用区映射。
- 检索对象 uuid 路由。
- 公开用于维护的 API。
- XJob
- 接收并处理来自 Nova API-GW、Cinder API-GW、Admin API 或 Neutron Tricircle 插件的跨 OpenStack 功能和其他异步作业。例如,当首次为租户启动 VM 时,路由器、安全组规则、FIP 和其他资源可能尚未在底层的 OpenStack 实例中创建。但这是必需的。与网络、安全组、ssh 密钥对等不同,其他资源必须在 VM 启动之前创建。这些资源可以异步创建,以加速首次 VM 启动请求的响应速度。
- 跨 OpenStack 网络也将以异步作业完成。
- Admin API、Nova API-GW、Cinder API-GW、Neutron Tricircle 插件中的任何一个都可以通过 RPC API 通过消息总线将异步作业发送到 XJob。
- 数据库
- Tricircle 拥有自己的数据库,用于存储 pod、pod 绑定、作业、资源路由表。
- Neutron Tricircle 插件重用 Neutron 的 DB,对于租户的网络,路由器将被分布到多个 OpenStack 实例,并管理租户级别的 IP/mac 地址,以避免跨不同 OpenStack 实例的冲突。
对于 Glance 部署,有几种选择
- 共享 Glance,如果所有 OpenStack 实例都位于高带宽、低延迟站点内。
- 共享 Glance 与分布式后端,如果 OpenStack 实例位于多个站点中。
- 分布式 Glance 部署,Glance 服务分布式部署在多个站点,并具有分布式后端
- 单独的 Glance 部署,每个站点都安装了单独的 Glance 实例和后端,不需要跨站点镜像共享。
值
开发 Tricircle 开源项目的动机
基于 PoC 设计的级联解决方案已经在几个生产云中运行,这表明了一个 OpenStack API 网关层具有网络自动化功能,位于多个 OpenStack 实例之上,无论是在大规模集中式云场景中,还是位于分布式边缘云中的分布式企业应用,甚至是混合云场景中,都具有价值
- OpenStack API 生态系统保留,从 CLI、SDK 到 Heat、Murano、Maganum 等,所有这些都可以无缝重用。
- 支持大规模云中的模块化容量扩展。
- 跨 OpenStack 实例的 L2/L3 网络自动化。
- 租户的 VM 通过 L2 或 L3 网络跨 OpenStack 实例进行通信。
- 跨 OpenStack 实例应用安全组。
- 租户级别的 IP/mac 地址管理,以避免跨 OpenStack 实例的冲突。
- 跨 OpenStack 实例的租户级别配额控制。
- 跨 OpenStack 实例的全局资源使用视图。
- 跨 OpenStack 实例的用户级别 KeyPair 管理。
- 由于租户级别的 L2/L3 网络,租户的数据可以在 OpenStack 实例之间移动。
- ...
安装和使用
在 Ubuntu 14.04 LTS 中使用 virtualbox 设置 Tricircle 在 3 个 VM 中。在 VirtualBox 中安装 Tricircle。
或者,请参阅 https://github.com/openstack/tricircle 中使用 devstack 的单节点/双节点设置的安装指南。
常见问题解答
问:Tricircle 和 OpenStack Cascading 有什么区别?
OpenStack Cascading 主要是一个在 2014 年底和 2015 年初进行的 PoC(概念验证)解决方案,旨在测试多个 OpenStack 实例可以部署在多个地理位置分散的站点,并通过基于 OpenStack 服务的 OpenStack API 层进行管理的想法。PoC 成功实施后,团队计划将核心理念贡献给社区。
Tricircle 正是基于这个想法而诞生的,但发展出了不同的形态和重点。与 PoC 中实现的 OpenStack Cascading 解决方案 V1 版本不同,后者包含大量的功能增强和复杂的组件,Tricircle 在早期阶段尝试构建一种干净、可扩展、可插拔和可重用的架构。
简而言之,OpenStack Cascading 是一个特定的部署解决方案,而 Tricircle 则代表一个独立的、解耦的服务集合项目,就像 Neutron、Nova 或 Glance 等其他 OpenStack 项目一样,未来可以应用于 OpenStack 生态系统。
问:Tricircle 的目标是什么?
短期内,Tricircle 将专注于开发健壮的架构和相关功能。从长远来看,我们希望能够成功建立一种可以应用于整个 OpenStack 社区的范例。
如何阅读源代码
要阅读源代码,按照以下蓝图会更容易:
实现无状态架构:https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
这个蓝图旨在从头开始构建 Tricircle
资源
- 设计文档:Tricircle 设计蓝图
- Wiki:https://wiki.openstack.org/wiki/tricircle
- 源代码:https://github.com/openstack/tricircle
- Bug 报告:http://bugs.launchpad.net/tricircle
- 蓝图:https://launchpad.net/tricircle
- 代码审查:https://review.openstack.org/#/q/project:openstack/tricircle
- 每周会议 IRC 频道:#openstack-meeting,irc.freenode.net,每周三 UTC 13:00 至 UTC 14:00
- 每周会议 IRC 日志:https://wiki.openstack.org/wiki/Meetings/Tricircle
- Tricircle 项目 IRC 频道:#openstack-tricircle on irc.freenode.net
- Tricircle 项目 IRC 频道日志:http://eavesdrop.openstack.org/irclogs/%23openstack-tricircle/
- 邮件列表:openstack-dev@lists.openstack.org,邮件主题中包含 [openstack-dev][tricircle]
- 新贡献者指南: https://docs.openstack.org/infra/manual/developers.html
- 文档:https://docs.openstack.org/developer/tricircle
- Tricircle 大型应用防御:https://review.openstack.org/#/c/338796(包含大量评论和讨论,可以从多个方面了解 Tricircle)
Tricircle 采用与其他 OpenStack 项目相同的提交和审查工具。因此,我们遵循OpenStack 开发流程。新贡献者应遵循入门步骤,因为需要 Launchpad ID 和已签署的贡献者许可协议才能添加新的条目。
历史记录
1. Tricircle 分裂前(有效期至 2016 年 10 月):https://wiki.openstack.org/wiki/tricircle_before_splitting
会议记录
所有会议日志和记录都可以在此处找到
2016:http://eavesdrop.openstack.org/meetings/tricircle/2016/
2015:http://eavesdrop.openstack.org/meetings/tricircle/2015/
待办事项
待办事项列表在 etherpad 中:https://etherpad.openstack.org/p/TricircleToDo
将 Tricircle 分裂成两个项目:https://etherpad.openstack.org/p/TricircleSplitting
团队成员
通过 IRC 频道 #openstack-tricircle 联系团队成员
当前活跃参与者
Joe Huang,华为
Khayam Gondal,戴尔
Shinobu Kinjo,红帽
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,华为
