跳转到: 导航, 搜索

Fog Edge Massively Distributed Clouds


雾/边缘/大规模分布式云 SIG 的目标是指导 OpenStack 社区,以最佳方式解决雾/边缘计算用例——定义为通过协作的 OpenStack 系统来监督和使用大量远程迷你/微型/纳米数据中心。FEMDC SIG 通过辩论和调查各种实施方案的需求来推进该主题。


状态:自 2018 年 5 月起暂停。

在成立一个更大的专门致力于边缘挑战的团队(跨不同的云/容器堆栈)之后,FEMDC 会议暂停,直至另行通知。 请参阅 边缘计算组 wiki 页面以获取更多信息。


Meetings

主席:Adrien Lebre (ad_ri3n_, 法国), Paul Andre Raymond (b-yond, 美国), Gergely Csatari (csatari, 匈牙利) 联系人:Adrien Lebre <adrien.lebre@inria.fr> Paul-André Raymond <paul-andre.raymond@b-yond.com> Gergely Csatari (gergely.csatari@nokia.com)

会议议程:https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018

问题描述

越来越多的学术界和行业专家提倡从大型集中式云计算基础设施转向在网络边缘大规模分布的较小基础设施。这种被称为“雾/边缘计算”的新兴范例,由于它提高了整个服务的敏捷性,并使计算资源更接近最终用户,因此越来越受到关注。然而,为了促进这种云计算范例的去中心化模式的采用,开发一个负责将复杂且多样化的资源网络转化为全球云的系统至关重要。

与其开发另一个代理系统,雾/边缘/大规模分布式云 SIG 的目标是

  • 研究当前 OpenStack 机制在多大程度上可以处理这种大规模分布式基础设施
  • 在适当的时候,提出对内部机制的修改/扩展。
  • 研究如何扩展当前的云 API,以利用地理分布(延迟感知应用程序,…)

在操作和使用不同的云时,云的代理/编排是首先考虑的方法。每个微型数据中心托管和监督自己的云,而代理服务负责通过在每个云上选择资源来提供资源。虽然这些自上而下的方法,使用简单的集中式代理,对于基本用例是可以接受的,但为了满足生产环境的要求(监控、调度、自动化配置、SLA 实施、配额管理、租户网络…),必须使用高级代理服务。除了处理可扩展性、延迟和单点故障问题外,代理服务变得越来越复杂,最终集成了每个 IaaS 管理器在操作每个站点时已经实现的大多数机制。

从上游开始:F/E/MDC SIG 的愿景是通过自下而上的方法来修改 OpenStack,最终目标是提供一种可以与其他实例原生协作的 OpenStack 架构,从而产生一个全球云的错觉。 这种方法 [1, 2] 应该能够通过尽可能地重用现有和未来的 OpenStack 生态系统来减轻开发工作。

值得注意的是,OpenStack 已经提出了初步机制来处理广域网部署 [3]。然而,尚不清楚当前的内部机制是否能够管理更大的分布式云计算平台(即,由数百个不同的站点组成)。除了识别大规模分布式基础设施的代表性用例外,SIG 想要执行的第一个行动是在多站点环境中分析 OpenStack 的不同核心服务(nova、keystone、horizon、glance、cinder、neutron 和 swift)的可扩展性以及通信模式。虽然一些倡议已经从 OpenStack 的角度调查了大规模分布式用例 [4, 5, 6],但对香草堆栈的严格分析仍然缺失。

这项研究将使社区能够识别主要挑战并回答以下问题:

  • 控制器可扩展性:应该/可以部署多少个控制器来监督整个基础设施?位于哪个位置?每个站点一个,还是多个站点一个?每个控制器需要多少个计算节点?
  • 我们应该有一个或多个端点?为什么?
  • 广域网限制(延迟/带宽方面):是否存在可能阻止核心组件正确运行的关键延迟约束?当前的服务是否足以应对广域网约束(VM 镜像,…)?
  • 一致性:如何保证核心服务状态的一致性?如果一个项目/VM/… 在一个站点上创建,其他站点的状态应该保持一致,以避免例如重复分配 ID/IP/…
  • 安全管理:雾/边缘基础设施是否会产生新的安全问题?如何确保不同位置之间通信的安全性?
  • 容错问题:如何修改 OpenStack,以保证一个(或多个站点)的崩溃或隔离不会影响其他数据中心?(每个站点应该能够独立运行。)
  • 可维护性:如何以一致的方式升级系统(考虑到升级整个基础设施可能需要大量时间,同时面临崩溃和断开连接问题)?换句话说,我们应该提出允许 OpenStack 在即使核心服务版本不同时也能正确运行的机制?
  • 多厂商互连(对等协议挑战、互操作性…)

完成这项研究后,就可以提出修改/扩展并讨论不同的方法。

[1] http://people.rennes.inria.fr/Adrien.Lebre/PUBLIC/MassivelyDistributed-101.pdf
[2] https://etherpad.openstack.org/p/massively-distributed-clouds-overview (在奥斯汀举行的初始大规模分布式 WG 提案)。
[3] https://docs.openstack.org/arch-design/multi-site.html
[4] https://openstack.org/assets/presentation-media/OpenStack-2016-Austin-D-NFV-vM.pdf
[5] https://wiki.openstack.org/wiki/Tricircle
[6] http://beyondtheclouds.github.io

使命

成为 OpenStack 多站点部署的公认专家论坛,并向 OpenStack 社区提供建议和输入。成为处理大规模分布式云计算挑战的催化剂,特别是通过识别合作机会。

与其他组的交互

如何参与

  • 注册 openstack-dev 邮件列表,并查找主题中带有“[FEMDC]”的帖子
  • 参加我们每两个月一次的 IRC 会议,时间为 UTC 时间周三下午 3:00 #openstack-meeting(提出您的议程项目并参与当前讨论)
  • 分享特定的用例或超级用户故事
  • 审查规范并提供您的意见
  • 将您的建议、问题等发送给 Adrien Lebre <adrien.lebre@inria.fr>
  • IRC 会议链接:请参阅 https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018(转到页面底部以查看/完成下一个议程)

Rocky 周期计划行动

(可以在我们的 IRC 会议期间提出其他行动)

  • 朝着去中心化 OpenStack 控制平面服务迈出一步。
  • 与 OPNFV 边缘 WG 合作,设计/部署边缘测试床。

已完成的行动

跨周期行动

  • 识别/研究/讨论将 OpenStack 分布到多个地理上相距遥远的区域的提案和新构建块。
  • 对于每个 OpenStack 核心服务,进行强评估以识别
    • 瓶颈
    • 阻塞设计选择(例如 rabbit+rpc 问题、ZeroMQ、…)
  • 产生可见的结果,供整个社区使用。Wiki 页面、峰会演示文稿。
  • 分析正在进行的行动的优缺点,并识别合作机会

之前的文档

悉尼,2017 年 10 月

波士顿峰会 etherpads,2017 年 5 月

往年会议议程/记录

巴塞罗那峰会 ether pad,2016 年 10 月


初始提案