Mercador

Mercador 是什么？

Mercador 是一个用于联合独立的 OpenStack 云的系统。这个名字来源于葡萄牙语中的 商人。

云服务的基本消费模式是云服务用户 (CSU) 和云服务提供商 (CSP) 之间的简单双向交互。CSP 部署一组服务并通过标准接口（支持 UI、CLI 和 API）发布它们。CSU 订阅这组服务（使用通常超出 OpenStack 范围的机制），并通过已发布的接口消费服务。无论服务多么复杂或地理分布，它们都由单个法律实体拥有和运营，该实体对它们的配置和管理拥有完全控制权。

现在出现了一些用例，这些用例要求我们扩展此模型。运营私有云的 CSP 希望为其用户提供对私有和公共云服务的统一访问。在一个地理区域运营的 CSP 想要在另一个国家/地区提供托管的服务（出于数据主权原因）；而不是在该国家/地区设置 OpenStack 云，它选择从另一个 CSP 采购这些服务。一家电信公司决定向其客户提供云服务，但它没有专业知识来做到这一点；相反，它更喜欢以自己的品牌从一个或多个 CSP 处转售服务。一个研究联盟希望从几家大学 CSP 处聚合云服务，并通过“单一面板”向其用户展示聚合的服务。

所有这些情况下的共同模式是，我们需要能够获取来自一个 CSP 的一组资源和服务，并使其可供第二个 CSP 使用，以便它可以被视为第二个 CSP 服务产品的一部分。CSU 不应知道所消费的服务是由与他们有合同关系的 CSP 实现的还是由第三方提供的。

原则

有五个重要原则影响着 Mercador 的开发方式。

• 首先，我们假设各个参与者——提供商、消费者、转售商、经纪人等——是独立的代理；没有单个机构可以实施和管理总体配置。每个 CSP 将继续管理其自身的用户入职、身份管理等策略。
• 其次，我们假设各种关系是动态的，但不是短暂的。这意味着系统必须支持发布-订阅绑定的程序化构建以及关系的长期管理。
• 第三，我们假设发布-订阅绑定的生命周期由超出 OpenStack 范围的业务和运营交互控制，并且系统必须由与这些交互相关的流程控制。
• 第四，我们希望 Mercador 尽可能地不具侵入性。理想情况下，CSP 应该能够通过部署单个软件包——Mercador 发布者——来发布资源，这将向服务目录添加两个 REST API 服务。CSP 应该能够通过部署 Mercador 订阅者软件包来发现和订阅第三方服务，该软件包添加一个 REST 服务。这两个服务都使用通用的 CLI 进行管理。CSU 不应看到任何更改。
• 第五，CSP 必须能够配置其发布的服务和资源的集合。它必须能够限制 OpenStack 服务集，实施配额和其他策略，控制图像、卷和网络等资源的可见性。它还必须能够配置订阅者可以消费的服务元数据。

术语

本文档中使用的术语如下

• 区域：通过单个令牌（服务目录加上身份信息）访问的 OpenStack 服务和资源的集合。几乎所有 OpenStack 资源和命名空间都限定于单个区域。一个 OpenStack Keystone 服务可以由多个区域共享，并将为每个区域提供不同的令牌。一个 OpenStack Horizon UI 可以通过与共享的 Keystone 配对来访问多个区域，从中确定可访问的区域。（基于 AVAILABLE_REGIONS 配置的第二个 Horizon 模式不受 Mercador 支持。）
• 项目：一个 OpenStack 项目。所有 OpenStack 资源分配操作都在特定项目的上下文中进行，并且必须由授权（通过 RBAC）在项目中执行操作的用户发起。所有分配的资源都“由”一个项目“拥有”。
• 分层多租户 (HMT)：项目可以由另一个项目在任意层次结构中“拥有”的系统。目前，大多数 OpenStack 服务不了解 HMT，因此它们在不考虑层次结构的情况下在单个项目的上下文中运行。预计未来各种 OpenStack 功能将得到增强以支持 HMT；例如，配额系统可能允许针对项目子树检查不同项目的资源使用情况。
• 域：任何项目都可以标识为域。如果域与特定的（非默认）身份管理策略相关联，则此策略将应用于所有子项目（除非在下级域中被覆盖）。OpenStack RBAC 框架允许向用户授予域本地管理权限。
• 虚拟区域：虚拟区域定义了 CSP 作为 Mercador 的一部分发布的一组服务和资源。CSP 通过指定现有区域内的域以及一组约束、策略和元数据来定义虚拟区域。当第二个 CSP 订阅虚拟区域时，它可以将其作为另一个区域提供给自己的 CSU；CSU 不应能够区分由 CSP 运营的区域和 CSP 订阅的区域。
• 发布者：提供虚拟区域的 CSP；同时，实现此功能的 Mercador 服务。
• 订阅者：消费和“转售”虚拟区域的 CSP；同时，实现此功能的 Mercador 服务。
• 服务聚合器：一种特殊的 OpenStack 配置，其中 CSP 不部署任何本地资源服务——Nova、Neutron、Cinder 等。服务聚合器提供的所有 OpenStack 服务都作为来自第三方 CSP 的虚拟区域采购。

用户故事

参与者

• Cumulus、Cirrus 和 Nimbus 是三个 OpenStack IaaS 运营商（云服务提供商，或 CSP）。Cumulus 和 Cirrus 提供公共云服务。Nimbus 主要从事支持其 SaaS 活动的业务。
• Chris 和 Pat 是 Widget Corp 的两名开发人员。
• Acme Corp 是 OpenStack 云服务的转售商。

用户故事 #1

Widget 希望向其开发人员提供 OpenStack 服务以构建内部应用程序。出于商业原因，它希望使用多个云提供商，但希望为其开发人员提供一致的用户体验。它与 Cumulus 和 Cirrus 签订合同以提供 OpenStack 服务。它部署了一个服务聚合器，允许 Chris 和 Pat 使用单个 Horizon 和 Keystone 来访问这两个云。

用户故事 #2

Nimbus 决定通过转售其部分 IaaS 容量来增加收入。但是，它不希望与最终用户打交道，涉及销售、支持和计费。相反，它与 Acme 签订合同以转售其 OpenStack 服务。

用户故事 #3

Cirrus 希望添加一个新的 OpenStack 服务，BDaaS（使用 Sahara）。但是，它没有支持大数据应用程序的内部专业知识。Cirrus 决定将 OpenStack 服务与 BDaaS 的转售外包给 Acme，同时防止其现有客户（如 Widget）访问 BDaaS。它通过创建两个虚拟区域来做到这一点。一个虚拟区域包括 BDaaS，并提供给 Acme；另一个不包括，并提供给 Widget。

用户故事 #4

Cumulus 遭受了重大中断，Widget 决定需要切换到另一个提供商。它与 Acme 签订合同以提供 OpenStack 服务。Acme 使用来自 Nimbus 的服务来满足此合同（故事 #2）。Widget 重新配置其服务聚合器，将 Cumulus 配置替换为 Acme 的配置。

用户故事 #5

Cumulus 的中断仍在继续，Cumulus 决定需要从第三方增加容量，以便能够继续为客户提供服务。Cumulus 与 Cirrus 签订合同以提供 OpenStack 服务。Cirrus 创建了一个虚拟区域，并将其提供给 Cumulus。Cumulus 配置此虚拟区域以使用其现有的 IDM 解决方案，以便其现有客户可以使用其常规凭据登录。

用例

TK

概述

用户（CSU）通常通过登录 Horizon 用户界面与云服务提供商（CSP）交互，并访问 OpenStack 区域中的计算、网络和存储资源。Keystone 服务处理身份管理 (IDM) 功能，并提供与区域中的服务交互的端点。（在这些图中，虚线表示独立的参与者。）

CSP 可以部署多个区域，并在所有区域之间共享 Horizon 和 Keystone 服务。用户登录 Horizon，选择要在其中工作的区域，然后获取所选区域的 Keystone 令牌。这提供了单点登录访问。但是，所有区域都由单个 CSP 管理，并且配置是静态的。（请注意，这取决于 Horizon 配置，在该配置中，区域列表是从 Keystone 获取的。它假定所有区域共享相同的 Keystone。这与 Horizon AVAILABLE_REGIONS 机制不兼容。）

用户可以使用两个不同的（独立的）CSP，但没有共享上下文；她必须将每个 Horizon 作为不同的会话登录。

假设区域 B1（由 CSP B 运营）具有一些吸引人的功能——地理位置或连接性——并且 CSP A 希望向其客户提供此服务。理想情况下，它希望区域 B1 看起来就像 Horizon 中的另一个区域，具有与 A1 和 A2 相同的 SSO。

设置起来显然很复杂。协商资源配额。协调项目和用户命名空间。配置 IDM。并且 OSS 和 BSS 系统（超出 OpenStack 范围）必须连接起来。理想情况下，我们希望能够动态地设置：发现合适的区域，并将其包含在可用资源中。

此外，CSP B 不太可能愿意提供无限制的访问权限（包括完全的管理权限）以访问区域 B1。相反，B 希望提供对一组资源、服务和管理权限的访问。我们称此包为虚拟区域

为了管理从一个 CSP 到另一个 CSP 的资源的访问过程，我们引入了两个新服务

• Mercado Publisher (M-pub) 设置虚拟区域并将其发布给其他 CSP。
• Mercado Subscriber (M-sub) 发现虚拟区域并使其可供用户使用。

主要工作流程如下

• CSP B 的管理员访问 M-pub B 以设置虚拟区域。为此，她使用与 M-pub 实现的 REST API 通信的 Python CLI 客户端。M-pub B 将虚拟区域配置存储在本地数据库中。
• CSP A 的管理员访问 M-sub A 以发现可用的虚拟区域。她提供了一份 Keystone URL 列表，这些 URL 来自提供联合服务的 CSP。M-sub A 调用每个指定区域中 M-pub 的 REST API，并检索每个可用虚拟区域的描述。（待定：此过程的身份验证和授权；一种方法是通过带外业务流程传输 Keystone token。）
• CSP A 的管理员指示 M-sub A 绑定来自 CSP B 的虚拟区域 B1。
  • M-sub A 与 M-pub B 通信以预留虚拟区域，并提供 CSP A 的 Keystone URL。
  • M-pub B 记录预留信息，并配置本地 Keystone，以便 CSP A 的 Keystone 处理虚拟区域的所有授权（使用 Keystone-to-Keystone）。
  • M-pub B 创建一个具有虚拟区域范围域内管理权限的本地用户。
  • M-pub B 为此管理员用户构建一个 Keystone token，列举正在提供的 OpenStack 服务，并将此 token 返回给 M-sub A。
  • M-sub A 配置其本地 Keystone，以使新的虚拟区域可用。
• CSP A 的 Horizon 从 Keystone 发现新的区域，并在“区域”下拉菜单中将其呈现给用户。

通过这种机制， “CSP” 实际上无需提供任何本地资源。我们这里有一个服务聚合器——转售商或经纪人——它从其他 CSP 获取所有区域。对于用户而言，它看起来就像任何其他 CSP 一样——UI、SSO、API。所有应用程序都需要在不进行任何更改的情况下运行。

目标是任何 OpenStack CSP 都可以通过部署 M-pub 和/或 M-sub 服务参与此系统，并且结果将通过 RefStack。必须强调的是，联合操作需要满足各种 OSS/BSS 要求。本项目仅解决 OpenStack。

约束

Mercador 架构中的 CSP 是独立的实体——通常是不同的法律实体，可能受不同的法律和合规性制度约束。他们还与现有客户建立了业务关系，这些关系不能受到损害。

身份管理

CSP A 的用户期望他们的个人信息仅由 CSP A 持有，而不是与 CSP B 共享。他们将使用 CSP A 支持的任何 IdP 登录到 CSP A。如果 CSP A 选择使用托管在 CSP B 运营的虚拟区域中的资源来支持用户，重要的是与 CSP B 共享的信息是 (a) 明确标识的，(b) 最小化的，并且 (c) 可能被匿名化。特别是，CSP B 必须不要求访问（甚至不知道）CSP A 中的 IDM 上下文。我们假设 CSP B 将使用 Keystone-to-Keystone 来处理此问题，并且 M-sub 将向 M-pub 提供必要的信息，以便设置 Keystone A。

域和项目

目标是虚拟区域的行为与常规区域相同——在功能和操作上。今天这是不可能的，因为域和项目名称空间存在限制。

远程管理

CSP A 的管理员需要能够管理其本地用户在“常规”区域或虚拟区域中托管的资源。虚拟区域的订阅过程必须包括创建必要的身份和角色，以提供此功能的步骤。一种方法是使用嵌套域。vregion B1 定义为域 B1-D1。CSP B 的 M-pub 可以创建一个本地（CSP B）用户，并授予此用户在此区域内的管理权限。然后，它可以创建一个下属域 B1-D1-Da，其 IdP 设置为 CSP A 的 Keystone。这确保了 CSP A 管理员可以登录到 CSP B 并管理 vregion，即使 K2K 出现故障。

Mercador 架构

TK

发布

TK

开发（蓝图、路线图、设计...）

TK

链接 & IRC

Mercador 讨论的 IRC 频道是 #openstack-mercador

http://webchat.freenode.net/?channels=openstack-mercador

已过时

有三个 Stackforge 仓库，分别对应于发布者、订阅者和 CLI 组件

https://github.com/stackforge/mercador-pub

https://github.com/stackforge/mercador-sub

https://github.com/stackforge/python-mercadorclient

结束 已过时

由于各种原因，我们决定 Mercador 的概念验证实现将基于 Keystone 和 CLI 客户端 openstackclient 和 keystoneclient 的分叉副本。仓库可以在这里找到

https://github.com/Mercador

以下 Trello 页面用于项目任务跟踪

https://trello.com/b/6tlmk3z4/mercador-stackforge-project

Meetings

会议每周五在 Freenode 频道 #openstack-meeting 上 UTC 1700 举行

议程和其他信息可以在 这里 找到。

团队

Geoff Arnold David Cheperdak Sean Perry Guang Yee

常见问题解答

TK

子页面

API 设计说明 (PDF)