【问题标题】:In AWS, how can I get physical instance ID from instance id?在 AWS 中,如何从实例 ID 获取物理实例 ID?
【发布时间】:2015-12-14 08:41:38
【问题描述】:

当我们使用小型 AWS 实例(例如 d2.xlarge 等)时,可能会将多个实例分配给同一主机。我想检查两个 vm 实例是否在同一主机上。有没有办法让我们获取 vms 的物理实例 ID?使用此信息,我们可以检查两个实例是否位于同一物理主机上。

这背后的主要动机是提高在云中运行有状态服务的可靠性。我们使用 d2.xlarge 实例在云中运行 hbase/kafka 工作负载。这些服务需要数据复制。因为一台物理主机最多可以托管 8 个 d2.xlarge 实例。如果一个物理节点宕机,可能会影响多个虚拟机实例,造成数据丢失。

【问题讨论】:

  • 你想用这些信息解决什么实际问题?
  • 我们试图避免在同一物理主机上放置两个或多个 d2.xlarge 实例——在这种情况下,如果下面的物理机发生故障,多个实例将停机。这对我们不利。

标签: amazon-web-services aws-ec2


【解决方案1】:

据我所知,亚马逊不会让您了解有关其底层基础设施的任何信息。而且我想不出他们应该这样做的理由。

但是我发现这个blog post说你可以使用CPUID指令来找出底层物理机的实际CPU。

来自那个帖子:

所有 x86 CPU 制造商都支持“cpuid”指令,并且 它旨在报告 CPU 的功能。本指令 是非陷阱的,这意味着您可以在用户模式下执行它而无需 触发保护陷阱。在 Xen 半虚拟化管理程序中 (亚马逊使用什么),这意味着管理程序将无法 拦截指令,并更改它返回的结果。 因此,“cpuid”的输出是真正的输出 物理 CPU。

话虽如此,如果您需要此信息以确保它们不会一次全部失败,我建议您使用从不同可用区启动实例。这样,即使整个 AZ 出现故障,您仍然可以启动并运行一些实例。

【讨论】:

  • cupid 无法唯一识别物理主机。
  • 我认为如果您使用 AWS,您必须采用他们的规则和方法。它不是您可以完全控制的数据中心,因此我建议您不要担心底层物理机器并寻找适当的方法来实现高可用性
  • 这不是专用租赁的意思。这意味着您的虚拟机将不会在共享硬件上运行。但是,如果您要启动专用的租赁机器,那么您的几个 VM 可以并且很可能会放置在相同的物理硬件上。这并不意味着您的每个虚拟机都有不同的专用硬件。我可以确认这一点,因为我收到了两个正在运行的虚拟机的“性能下降,您的实例底层硬件将过期”的通知。
  • @greg_diesel:我调查了它,你是对的,所以我删除了那部分。感谢您指出这一点。
  • 我仍然认为在云上运行虚拟机时试图找出物理机是徒劳的,而且绝对是错误的方法。
【解决方案2】:

AWS 没有提供关于获取 VM 放置信息的官方支持。一些大型 AWS 客户能够获得这方面的定制支持。

【讨论】:

    猜你喜欢
    • 2020-12-09
    • 2010-10-12
    • 2019-07-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多