Jacket

概述

现在有很多人和企业在使用私有云和公有云，例如 OpenStack、VMware vCloud Director、AWS、Azure 等。由于云的 API 模型各不相同，用户会遇到以下问题

学习成本高：用户需要花费大量时间学习如何使用新云的新的 API。
在新云中部署业务的工作量大：当用户想在新云中部署他们的业务时，需要大量的工作来重新开发业务部署工具，或者使用新云提供的 API 手动部署业务。
难以在不同的云之间扩展工作负载：没有不同云的统一资源管理，用户需要开发跨云扩展工具，这并不友好，因为该工具需要用户了解不同云中业务配置的差异。

Jacket 项目的目标是为这些异构云提供标准的 OpenStack API 模型。

用例

跨云部署

一个典型的 Web 应用程序由 3 个不同的层组成，负载均衡器层、Web 前端层和应用程序后端层。用户拥有基于 OpenStack 或 VMware 等的私有云，该私有云资源较少但比公有云更安全。因此，他们可以使用标准的 OpenStack API 在私有云中启动 Web 服务的后端虚拟机，在公有云中启动负载均衡器和 Web 前端虚拟机。

云爆发

在某些情况下，用户如果不是必要的话，不想将任何东西放在公有云中。用户通常希望将应用程序的所有部分放在私有云中，并且希望在出现“云爆发”时扩展 Web 前端。例如，我在我的私有云中有一个在线购物中心，在正常情况下系统资源和互联网带宽足够。但在大型节日期间会出现瓶颈，因此我希望在该期间将我的应用程序扩展到公有云，并在大型节日结束后将我的应用程序缩回到私有云。

挑战

如何统一计算和块存储管理？

有两种方法可以统一计算和块存储管理。

一种方法是 Jacket 项目为 AWS、Azure、VMware vCloud Director 等提供标准的 nova-compute hypervisor 驱动程序和 cinder-volume 驱动程序。AWS、Azure 等将被管理为不同的 hypervisor，就像 KVM、Xen 等一样。

但是，此解决方案存在以下弱点

由于标准的 nova-compute 和 cinder-volume 无法提供 restful API，因此提供商云中的一个帐户只能用作 nova-compute 和 cinder-volume 驱动程序中的静态配置。当用户想修改管理帐户时，他们必须修改静态配置并重新启动 nova-compute 和 cinder-volume，并且他们无法通过 OpenStack 使用提供商云。
OpenStack 管理的提供商云中的可用资源数量恰好等于提供商云中一个帐户的配额。并且 OpenStack 中的所有项目共享资源，每个项目的配额必须小于提供商云中的配额。这可能对用户来说是不可接受的。
由于与访问帐户管理相同的原因，OpenStack 和提供商云之间的 flavor 的关联只能作为 nova-compute 中的静态配置。因此，当提供商云添加或更新 flavor 时，用户必须更新配置并重新启动 nova-compute。
当用户在提供商云中拥有遗留的计算和块存储资源时，我们只能提供一个工具将遗留资源的 data 注入 nova 和 cinder 的数据库中。显然这不是一个好的解决方案。

另一种方法是，Jacket 将作为独立的服务来管理不同的云，并提供计算、块存储 restful API 和提供商云配置 restful API。计算和块存储 API 用于管理提供商云中的资源以供 OpenStack 驱动程序使用。多个 API 用于管理项目、镜像、flavor 等的关联。这个解决方案就像 OpenStack 使用 Ironic 服务管理裸机服务器一样。

与第一种解决方案相比，此解决方案具有以下优势

Jacket 将提供 API 来配置在 OpenStack 中创建的项目与提供商云中的帐户之间的关联。用户可以在不重新启动任何服务的情况下添加或更新关联。
一个项目或多个项目可以与提供商云中的一个帐户关联。因此，一个项目可以拥有提供商云中的一个帐户的配额，并且还可以与其他项目共享它。
Jacket 提供 API 来配置在 OpenStack 中创建的 flavor 与提供商云中的 flavor 之间的关联。根据用户的用例，不同提供商云中的相似 flavor 可以与 OpenStack 中的相同或不同的 flavor 关联。当提供商云添加新的 flavor 时，用户可以创建新的 flavor，然后动态地将其与提供商云中的新 flavor 关联。
Jacket 提供带有 restful API 的遗留资源采用功能。在该功能中，Jacket 将调用 nova 和 cinder 的资源分配 API 来在它们的数据库中创建记录，当 nova 和 cinder 调用 Jacket 时，Jacket 将查找相应的遗留资源而不是创建新资源。

云与 hypervisor 非常不同，例如 hypervisor 没有租户管理、镜像管理、flavor 管理等。因此，第二种解决方案，Jacket 作为独立的服务并提供 restful API，会更好。

如何统一网络管理？

有一个解决方案是使用 OpenStack Neutron 通过基于提供商云虚拟网络的覆盖虚拟网络提供统一的网络功能。这将是另一个项目，Jacket 项目将不包括这部分内容，而只关注统一的计算和块存储管理。

如何统一镜像管理？

提供商云对镜像有不同的需求，一个镜像无法在所有提供商云中运行。如何统一镜像管理？有一个解决方案是用户将镜像上传到提供商云，Jacket 提供 restful API 允许用户将 OpenStack 中没有镜像文件的镜像与提供商云中的镜像关联。

架构

Jacket 将提供统一的 API 模型来管理提供商云。Jacket 具有以下功能

帐户管理：管理提供商云的帐户，以及 OpenStack 中的项目与提供商云中的帐户之间的关联。
Flavor/镜像统一管理：管理 OpenStack 中的 flavor/镜像与提供商云中的虚拟机 flavor/镜像之间的关联。
假卷管理：提供假卷管理以屏蔽某些提供商云中缺失的卷功能。
一致性检查：检查 OpenStack 中的资源与提供商云中的实际资源之间的一致性。

Jacket 可以作为集群部署。Jacket 集群可以同时管理多个提供商云，并且我们也可以部署多个 Jacket 集群，在每个 Jacket 集群只管理一个提供商云的情况下，管理大规模虚拟机。

OpenStack 将通过 nova-compute/cinder-volume 驱动程序调用 Jacket，就像调用 Ironic 来管理裸机服务器一样。将有一个 nova-compute 和 cinder-volume 来管理每个提供商云的每个可用区中的资源。每个 nova-compute/cinder-volume 都有不同配置的提供商云中管理的可用区的名称。

Jacket 专注于如何使用 OpenStack API 模型统一云的 API 模型，以及如何使用一个 OpenStack 实例来管理一个提供商云。还有另一个项目 Tricircle 专注于如何管理多个 OpenStack 实例以及跨多个 OpenStack 实例的网络自动化。因此，使用 Tricircle 同时管理多个不同的云是一个很好的解决方案，每个云都通过 Jacket 由 OpenStack 实例管理。

常见问题解答

问：Jacket 是一种不同云的 API 网关吗？

Jacket 不是不同云的 API 网关。Jacket 的目标是为不同云提供统一的 OpenStack API 模型，因此 Jacket 的主要任务是通过 Jacket 中的子服务来屏蔽提供商云和 OpenStack 之间的差异。例如

统一资源 uuid 分配：当用户调用 Jacket 资源创建 API 时，Jacket 将根据其自身的 uuid 格式为资源分配 uuid，然后将其与提供商云中的唯一标识符关联，因为不同的唯一标识符和云中的不同行为。例如 1) AWS 不支持从 AMI 镜像创建卷并从启动卷启动 VM。因此，当用户使用 Jacket 在 AWS 中从卷创建 VM 时，Jacket 将只在数据库中创建一个卷记录并返回其 uuid，在 AWS 中创建 VM 后，Jacket 将获取 AWS 中的启动卷的 uuid 并将其写入数据库中的映射表。 2) 创建卷的快照，AWS 将只返回一个作业 ID，并且用户将在作业启动后获取快照的 ID。Jacket 将返回 Jacket 分配的快照 uuid，然后它将定期查询 AWS 中的快照 ID 并将其写入数据库中的映射表。
假卷管理：某些云没有完整的卷管理，例如，VMware vCloud Director 没有启动卷对象，并且不支持卷的备份和快照，因此 Jacket 将为这些云实现这些功能。

云的行为和功能会有更多的差异。Jacket 将屏蔽上述提到的差异。

问：Tricircle 和 Jacket 之间的关系是什么？

Jacket 专注于如何使用 OpenStack API 模型统一云的 API 模型，以及如何使用一个 OpenStack 实例来管理一个提供商云。Tricircle 专注于如何管理多个 OpenStack 实例以及跨多个 OpenStack 实例的网络自动化。因此，使用 Tricircle 同时管理多个不同的云是一个很好的解决方案，每个云都通过 Jacket 由 OpenStack 实例管理。