Nova实例引用

Launchpad 条目: Nova规范: https://blueprints.launchpad.net/nova/+spec/nova-instance-referencing

创建时间: 2011年3月29日

更新时间: 2011年4月14日

起草人: Ed Leafe

起草人邮箱: ed@leafe.com

总结

随着区域（zones）添加到 OpenStack，我们在寻址实例时出现了一个复杂情况，因为目前实例是通过主键（Primary Key）引用的，这是一个自动递增的整数。这是当前Rackspace API的一部分。添加区域，每个区域都有自己的数据库，意味着这些PK之间没有唯一性的保证；事实上，重复几乎肯定会发生。我们需要讨论替代方案，权衡它们的工作效果以及它们将如何影响当前的nova代码以及API。

主要解决方案

更改为全局唯一的PK，其中UUID是最明显的候选者。
保留当前的ID字段，但更改API以使用复合键方法，该方法涉及将区域路径添加到实例中，因为ID在其区域内将是唯一的。
要求安装手动分区可能的PK值范围，以便在不同区域中生成的键不会重叠。

原理

一旦引入区域和“共享无”的可扩展性方法，关于唯一标识符的假设不再有效。有两个独立的考虑因素：数据库PK的唯一性和API寻址的唯一性。上述所有三种方法都将满足数据库方面的考虑；本次讨论的重点将是哪种方法将为API（内部和外部）提供最佳解决方案。

用户故事

作为Nova的客户，我需要能够唯一地寻址我的实例，以便能够以编程方式与它们交互。

作为Nova的开发者，我需要在特定的区域中寻址一个实例，而无需不断检查每个区域，以便减少带宽和延迟。

作为Nova的管理员，我需要允许我的客户访问他们的实例，而无需暴露内部结构，以便减少基于此类内部知识的攻击向量。

前提条件

每个区域都有自己的数据库。数据在区域之间不共享
区域作为逻辑结构，可以根据需要进行更改，并且不应更改访问实例的URI。

每种方案的优缺点

UUID

优点
1. 易于生成
2. 广泛使用；成熟的技术
缺点
1. 人类难以使用
2. 需要对Nova代码库进行大量更改，该代码库假定ID是整数。是的，我知道UUID实际上是128位整数，但通常以字符串表示形式使用。
3. 不提供有关定位实例主机的任何信息。要操作一个实例，必须搜索区域层次结构以找到目标实例。

复合键

优点
1. 标识实例在嵌套区域配置中的位置
2. 不需要对数据库进行本地更改
缺点
1. 极大地限制了灵活性 - 更改逻辑区域布局将破坏所有当前的URI
2. 需要对Nova API进行大量更改，而当前的Nova API没有区域位置的概念。
3. 在公共URI中包含有关内部结构（即区域布局）的信息被认为是一种安全漏洞。

分区PK范围

优点
1. 不需要更改当前的API
2. 不需要更改代码库
3. 不需要更改数据库
4. 将有助于寻址给定的实例，因为它的ID将与特定的区域相关联。
缺点
1. 手动密集型 - 每个区域都必须单独配置
2. 当达到范围限制时，将需要密钥生成代码最终必须重新使用旧密钥
3. 需要提前知道给定区域可能需要处理的实例数量。
4. 范围将暴露有关节点物理位置的一些信息。
5. 极其hackish且丑陋，随着部署的增长，可扩展性也存在问题。

拟议的解决方案

基于以上，我建议采用UUID方法。虽然它可能需要更多代码更改来实现，但从长远来看，它提供了最佳的可扩展性和安全性组合。在复杂的区域配置中定位实例的问题是其最大的长期缺点，但可以通过类似于当前区域“了解”其分支中可以处理的内容的功能的缓存解决方案来解决。

当然，这个解决方案并非一成不变，否则为什么还要进行峰会讨论？

讨论议程

请添加您能想到的上述部分中的任何其他优缺点。在峰会上，我想讨论这些不同方面，如果问题提前记录下来，我们都可以为更深入的讨论做好准备。