OpenStack Edge Discussions Dublin PTG
目录
简介
此页面收集了都柏林 PTG 边缘研讨会讨论的主题。 如果此页面有任何错误或缺少信息，请直接进行更正。
讨论记录在以下 etherpads 中
定义
- 应用可持续性：已部署在边缘站点上的 VM/容器/裸机（即工作负载）可以继续提供请求，即本地用户可以 ssh 连接到它
- 控制站点：仅托管控制服务的站点（即这些站点不旨在托管计算工作负载）。 请注意，目前还没有特别需要这样的站点。 我们只需要控制站点定义来进行差距分析和可以考虑的不同部署场景。
- 边缘云基础设施用户：通过边缘云基础设施的不同 API 与边缘云基础设施直接联系的用户。
- 边缘云服务用户：使用在边缘云基础设施中运行的服务用户。 这些用户不与边缘云基础设施交互，并且在理想情况下，他们不知道边缘云基础设施的存在。
- 边缘站点：服务器可能提供控制和计算能力的站点。
- 原始站点：最初执行/执行操作的站点。
- 远程站点：受从原始站点启动的操作影响的站点。
- 站点可持续性：本地管理员/本地用户应能够在断开与远程站点的连接时管理/使用本地资源。
- MVS（最小可行解决方案）：边缘云解决方案所需
- 非 MVS：边缘云可以在没有这些组件的情况下是可行的
远程和原始站点示例
在下图中，边缘云站点 1 是操作的原始站点，而边缘云站点 2 和 3 是操作的远程站点。 原始站点中的操作员始终由边缘云基础设施的用户触发，而在远程站点中，则由原始站点或远程站点触发。 
边缘用例
然而，etherpads 中没有记录，关于边缘云用例的讨论很多。 边缘计算组将用例收集到 OpenStack 边缘计算白皮书 中，该白皮书可从 openstack.org 的边缘部分 以及边缘计算组 wiki 的特定 用例部分 获取。
部署场景
部署场景在 OPNFV Edge Cloud 项目的 白皮书 中描述。
特性和需求
讨论发生在两个层面 1) 在边缘云的未来特性层面，以及 2) 在试图部署边缘云的那些人今天缺失的具体需求层面。 这些特性和需求处于不同的层面，因此它们记录在两个单独的子章节中。
架构范式
- 在一种边缘基础设施中，云元数据具有单一的事实来源
- 可以缓存数据
- 边缘基础设施的任何边缘云实例之间都可以进行网络分区
特性
特性按不同的特性组组织，从 单个站点上的基本操作 到最先进的特性集。
特性的基本假设
- 数百个边缘站点需要由单个运营商和多个运营商进行操作
- 每个边缘站点至少由 1 台服务器组成
- 根据设想的场景，可以有一个或多个 控制 站点（控制站点和边缘站点之间的延迟可以从几毫秒到数百毫秒不等）。
特性
单个站点上的基本操作
类型：MVS
- 管理操作
- 创建角色/项目
- 创建/注册服务端点
- 遥测（收集有关基础设施和 VM 的信息）
- 运营商操作
- 创建 VM 镜像
- 本地创建 VM
- 创建/使用远程附加卷
- 遥测（收集有关基础设施和 VM 的信息）
使用远程站点
类型：MVS
凭据仅存在于原始站点
- 运营商操作
- 远程站点上的所有 单个站点上的基本操作
- 运营商应能够定义一个明确的远程站点列表，操作应在该列表中执行
- 站点之间共享项目和用户。 注意： 存在一个担忧，即这会导致非共享无配置。 问题是是否有其他方法可以避免将此数据手动配置到每个边缘站点。
边缘云实例之间的协作
类型：非 MVS？
- 站点之间共享 VM 镜像
- 站点之间创建网络
- 创建网状应用程序（即在多个站点上部署的多个 VM）
- 使用远程“远程附加”卷 - 请注意，远程附加卷存储在远程站点上（而在 L1/L2 中，远程卷存储在本地）
- 将工作负载从一个站点迁移到另一个站点
- 应有一种方法来发现和协商站点功能作为迁移目标。 超visor 和超visor 功能可能存在差异。
- 不同的超visor 可能会使用不同的 VM 镜像格式
- 使用不同的超visor 特定的镜像，这些镜像是从相同的原始镜像派生的元数据 - 还要知道在哪里启动镜像（哪个站点）
- 使用经过特定超visor 池测试的通用镜像 - 这样就可以保证镜像为 X、Y、Z 超visor 认证（甚至可以使用超visor 版本粒度？）
- 冷迁移
- 实时迁移
- 需要计算节点之间的直接连接 - 例如，通过某种点对点覆盖连接（例如通过 IPsec）在两个计算节点（源 + 目标）之间
- 如何处理附加的 cinder 卷？
- 温和迁移
- 拍摄 VM 快照并移动它
- 边缘云基础设施的真实性应是一种能力
- 利用在另一个站点创建的 flavor。
- 在一组站点上推出一个 VM
- 定义协作范围/半径（即，应该能够显式定义可以启动工作负载/特定租户可以保存数据的站点。）
网络不可靠性
类型：非 MVS
- 控制和受控组件都应为不可靠的网络做好准备，因此它们应
- 具有操作重试策略，而不会使网络过载
- 能够在网络中断时暂停通信，并在网络恢复后重新启动它
- 隔离的边缘云站点的用户应能够执行有关该站点的操作。
- 在网络分区的情况下，每个分区的每一侧都应可操作。
- 开放问题:
- 我们是否期望在网络分区的情况下缓存操作？
- 网络分区恢复后如何处理配置数据冲突？
容器
类型：MVS？
与 边缘云实例之间的协作 相同，但适用于容器。
边缘云实例之间的自动调度
类型：非 MVS 与 边缘云实例之间的协作 和 容器 相同，但以隐式方式进行。
- 边缘兼容的调度器/放置引擎
- 边缘云实例和调度器/放置引擎应了解边缘云实例的物理位置
- 工作负载应为了性能目标而自动重新定位（遵循最终用户，...）
- 边缘兼容的应用程序编排器（类似于 heat 的方法）
- 边缘站点内或边缘站点之间的主机自动缩放....（这需要类似于 ceilometer 的系统）
- 授权加入边缘云实例集群的新主机
管理特性
类型：MVS？
- 零触控配置（例如，从裸机 Rack Scale Controller (RSC) 到 OpenStack）
- 主机操作系统配置
- 基于 kolla/kubernetes/helm 的 OpenStack 部署
- 加入边缘云基础设施（边缘云实例和边缘云基础设施的身份验证）
- 问题：网络设备呢？
- 远程硬件管理（清单、eSW 管理、BIOS 和类似配置）
- 远程升级（OpenStack 核心服务）。
- 控制平面的服务连续性
- 工作负载的服务连续性
- 控制平面版本问题
- 这与能力发现有些类似
- 监控服务通过通知/触发获取重要事件。
- 日志和警报
- 日志/警报和事件
- 日志、警报、事件和性能指标
- 边缘站点之间延迟相关的新性能指标
- 构建实时监控仪表板（以及按需构建，以便定义管理员想要按需监控的资源的范围）
- 用于维护操作、能源优化（绿色能源 - 太阳能电池板/风力涡轮机..）的工作负载整合/重新定位
- 在每个边缘站点上执行特定操作（仅配置我的用户和租户一次，以便配置在所有边缘云中保持一致）
- 其他自主机制
- 收集边缘站点上的信息并基于此执行操作（自动缩放）
- 处理磨损挑战（边缘出现/删除）
- 基于人为因素与基于崩溃。
- 连接新配置的边缘站点的网络
- 边缘基础设施不同部分的运营商应了解其操作域（上帝模式用户可以看到所有内容，而区域边缘云的运营商可以看到实际边缘云的数据）
- 能够查看云的云，并为该云的用户提供一组特性和一组可以使用这些特性的节点。
多云堆栈
类型：MVS？
不同版本的 OpenStack 和 Kubernetes 实例
- 边缘云实例之间的协作、容器、边缘云实例之间的自动调度 和 管理特性 特性，但适用于不同版本的 OpenStack
- 边缘云实例之间的协作、容器、边缘云实例之间的自动调度和管理功能，不同的云解决方案（例如：OpenStack 或 Kubernetes）
多运营商场景
注意：本节比此页面的其余部分更草稿化。
注意：需要考虑运营商到边缘 ID 的映射。
类型：非 MVS？
- 安全注意事项
- 保证应用程序的虚拟机或容器之间的通信是安全的
- (物理)安全问题（我们能限制人为拜占庭攻击者吗）
- 数据隐私（管辖权问题）
- HA / 可靠性 / 恢复挑战
需求
本节收集针对现有或新开源项目的具体需求。
位置感知
边缘云站点应了解其位置
组件：OpenStack Keystone？ / Kubernetes？
边缘云实例应该能够存储关于其位置的数据。
元数据分发
发现数据源
组件：同步服务
边缘云实例应该能够发现其他可信赖的边缘云实例作为元数据的来源。
注册同步
组件：同步服务
能够提供元数据同步服务的边缘云实例应该能够为希望接收数据的边缘云实例提供注册 API。数据应在首次成功注册后同步。边缘云实例应该能够为元数据同步服务注册自身。
宣传元数据数据源服务
组件：同步服务或 OpenStack Keystone
边缘云实例应该能够宣传它是否能够提供元数据同步服务
用户管理数据源侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够提供用于同步的用户数据。要同步的用户要么被标记（通过 API、CLI 或配置文件），要么通过同步接收。调用目标边缘云的用于用户管理数据的 API。如果发生错误，有问题的分段将被标记为重试，并重试直到收到 200 OK。如果同步的数据发生更改，则应将其重新同步到所有接收边缘云实例。
用户管理数据接收侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够利用来自远程站点的用户，这意味着用户无需手动将用户配置到边缘云实例即可登录到边缘云实例。
边缘云实例可以通过同步接收用户。在这种情况下，应提供一个 API，用户管理数据可以在其中设置。只有正确存储的数据才提供 200 OK。接收到的数据应被锁定以防止本地编辑。
或者，边缘云实例可以根据一组预配置的策略和首次登录尝试时可用的信息自动配置用户。预配置的策略应被同步或静态。
RBAC 数据源侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够提供用于同步的 RBAC 数据。要同步的 RBAC 数据要么被标记（通过 API、CLI 或配置文件），要么通过同步接收。调用目标边缘云的用于 RBAC 数据的 API。如果发生错误，有问题的分段将被标记为重试，并重试直到收到 200 OK。如果同步的 RBAC 数据发生更改，则应将其重新同步到所有接收边缘云实例。
RBAC 数据接收侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够通过同步接收 RBAC 数据。应提供一个 API，RBAC 数据可以在其中设置。RBAC 数据应与边缘云实例的用户数据一致。只有正确存储的数据才提供 200 OK。接收到的数据应被锁定以防止本地编辑。
VM 镜像源侧
注意：在单独的wiki页面中讨论了边缘环境中镜像处理的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Glance 或 Glare
边缘云实例应该能够提供选定的 VM 镜像进行同步。要同步的 VM 镜像要么被标记（通过 API、CLI 或配置文件），要么通过同步接收。调用目标边缘云的用于 VM 镜像数据的 API，其中提供镜像的哈希值，为磁盘镜像构建数据路径，并传输磁盘镜像（确切技术是 FFS）。如果发生错误，有问题的镜像将被标记为重试，并重试直到收到 200 OK。如果任何同步的 VM 镜像被更新，则应将其重新同步到所有接收边缘云实例。应该有一个 API，接收边缘云实例可以发起特定 VM 镜像的同步。应该维护镜像的版本。
VM 镜像接收侧
注意：在单独的wiki页面中讨论了边缘环境中镜像处理的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack OpenStack Glance 或 Glare
边缘云实例应该能够通过同步接收 VM 镜像。应提供一个 API，可以发起 VM 镜像传输，构建传输的数据路径，并检查接收到的镜像的哈希值。只有正确存储的数据才提供 200 OK。接收到的数据应被锁定以防止本地编辑。
Flavors 源侧
组件：同步服务、OpenStack Nova、Kubernetes
边缘云实例应该能够提供选定的 Flavors 进行同步。要同步的 Flavors 要么被标记（通过 API、CLI 或配置文件），要么通过同步接收。调用目标边缘云的用于 Flavors 的 API。如果发生错误，有问题的 Flavor 将被标记为重试，并重试直到收到 200 OK。如果任何同步的 Flavors 发生更改，则应将其重新同步到所有接收边缘云实例。
Flavors 接收侧
组件：同步服务、OpenStack Nova、Kubernetes
边缘云实例应该能够通过同步接收 Flavors。应提供一个 API，可以在其中设置 Flavors。只有正确存储的 Flavors 才提供 200 OK。接收到的数据应被锁定以防止本地编辑。
Projects 源侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够提供选定的 Project 配置进行同步。要同步的 Projects 要么被标记（通过 API、CLI 或配置文件），要么通过同步接收。调用目标边缘云的用于 Projects 的 API。如果发生错误，有问题的 Projects 配置将被标记为重试，并重试直到收到 200 OK。如果任何同步的 Projects 发生更改，则应将其重新同步到所有接收边缘云实例。
Projects 接收侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够通过同步接收 Projects。应提供一个 API，可以在其中设置 Projects。存储的 Projects 应与边缘云的用户设置一致。只有正确存储的 Projects 才提供 200 OK。接收到的数据应被锁定以防止本地编辑。
Quotas 源侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够提供选定的 Quota 配置进行同步。要同步的 Quotas 要么被标记（通过 API、CLI 或配置文件），要么通过同步接收。调用目标边缘云的用于 Quotas 的 API。如果发生错误，有问题的 Quota 配置将被标记为重试，并重试直到收到 200 OK。如果任何同步的 Quotas 发生更改，则应将其重新同步到所有接收边缘云实例。
Quotas 接收侧
注意：在wiki页面中讨论了边缘环境中 Keystone 元数据同步的替代方案。本章的最终内容取决于在那里讨论的解决方案。
组件：同步服务、OpenStack Keystone、Kubernetes
边缘云实例应该能够通过同步接收 Quotas。应提供一个 API，可以在其中设置 Quotas。存储的 Quotas 应与边缘云的 Projects 设置一致。只有正确存储的 Quotas 才提供 200 OK。接收到的数据应被锁定以防止本地编辑。
进度监控
组件：同步服务
具有元数据同步服务的边缘云实例应该能够
- 报告其自身在数据分段和目标边缘云实例方面的进度
- 收集其“下方”的具有元数据同步服务的其他边缘云实例的报告
- 报告其自身和所有其他“下方”同步服务的进度
单一监控和管理界面
可操作性数据聚合数据提供方部分
组件：同步服务或其他？
边缘云实例应该提供一个 API，它们可以在其中提供关于自身的可操作性数据。
提供的数据应为
- 活动警报列表
- 还有什么？
可操作性数据聚合数据聚合方部分
组件：同步服务或其他？
一些选定的（边缘）云实例应该能够收集其他边缘云实例的可操作性数据，并在 UI 和 CLI 上显示这些数据。
远程控制控制部分
组件：同步服务或其他？
一些选定的（边缘）云实例应该能够对其他选定的边缘云实例发出不同的操作。支持的操作应为
- 添加操作。
远程控制接收部分
组件：同步服务或其他？
边缘云实例应该能够通过 API 远程接收命令。
已识别的未解决问题
- 我们如何区分从回程到边缘站点的连接（即边缘站点之间的连接），与边缘站点和附近开发/用户的连接？
- 关于小型边缘部署的存储：存储是单个本地连接的单元吗？
- 关于小型边缘部署的存储：镜像仓库服务怎么样（即，您期望一个完全独立的边缘节点，还是我们可以设想只有一个像 OpenStack 术语中的计算节点一样运行的节点？）
- 在边缘，许多 vm/cn 应用程序会根据需要演变。对于这种应用程序管理有什么想法？
- 在不同的边缘部署场景中，所有 OpenStack 组件的大小应该是多少，包括 CPU、内存、磁盘和硬件单元？
