AWS：实例和可靠性

Question

除了创建巨大的实例之外，有没有办法强制实例在单独的物理机器上运行，或者检测亚马逊网络服务 (AWS) 上同一图像的多个实例正在使用多少物理机器？

我在这里考虑可靠性。如果我自欺欺人地认为我有三个独立的服务器用于容错（想想 Paxos、Quicksilver、ZooKeeper 等），因为我运行了三个不同的实例，但所有三个最终都运行在同一台物理机器上，我可能会一个非常非常粗鲁的惊喜。

我意识到使用单独的区域可能会强制解决此问题，但如果有区域内甚至可用区域内的解决方案，我会很高兴，因为我不确定我是否见过 AWS在创建实例时，实际上在所谓的多选下拉菜单中为我提供了多个可用区选项。

---

好的，我很欣赏前两个回答我的问题的建议，但我试图通过在一个地区放置 3 台机器来简化问题而不写小说。让我再试一次 - 当我向上/向外扩展假设的应用程序堆栈时，我将静态和动态（“弹性”）添加实例。当然，任何形式的故障/灾难都可能发生（包括整个数据中心因不幸的休息室事故而烧毁，其中涉及微波炉、CD 和两个白痴说“哦，是吗？看这个！！ ！”），但到目前为止，最有可能的是某种硬机器故障，紧随其后的是死端口。在单个虚拟化硬件上运行相同类型 T 的多个实例会增加计算能力，但不会增加容错能力。显然，如果我要扩大/扩大规模，我很可能会使用“更大”的实例。显然，如果 AWS 最大的机器有内存大小 M 和处理器数量 C，如果我选择一个内存大小为 m 的实例，使得 m > (M/2) 或 CPU 大小为 c 的数量，使得 c > ( C/2)，那么我将保证我的实例在不同的机器上运行。但是，我不知道今天的 M_max 和 C_max 是什么；我当然不知道一年后它们会是什么，或者从现在起两年后，等等，因为亚马逊收购了 Bigger Better Faster。我知道这听起来像是吹毛求疵，但不知道实例是如何分布的，或者是否有控制实例分布的机制意味着我可以在使用当前计算影响 F+1 或 2F+1 时在假设中犯真正的错误分布式计算算法或评估用于新应用程序的新算法、分片和位置决策、应用程序堆栈中流量较少的部分的最小保留与弹性实例计数等。

Answer 1

每个区域始终至少有两个可用区，这应该适用于高可用性方案。 Intra-az 在可靠性方面不会走得太远，因为整个 az 可能会下降（不太可能，但可能）。

如果您绝对必须强制“intra-az 独立硬件”，则不同帐户中的专用实例可以实现这一点，但成本会更高，而且不会更好。

Answer 2

不仅有多个可用区（想想单独的数据中心），在每个区域内，您还可以将服务器分成不同的区域（西海岸、东海岸、欧洲等）。

就冗余和可靠性而言，最好将工作分散到 AZ 和区域，然后尝试找出或确保单个 AZ 内的实例位于同一硬件上。