AWS EBS块大小

Question

您能指点我一些EBS如何在gp2卷幕后工作的资源吗？ 我理解它的方式，它是一种服务，但实际上它是以一种冗余的方式将SSD驱动器阵列连接到实例的某种形式 什么是实际的物理连接方法？ 该文档涉及数据以16KB或256KB块传输的事实，但我无法再找到有关这方面的信息。 例如，如果在Linux中，我的分区是用4KB块格式化的，这是否意味着EBS将以16KB块的形式向/从磁盘传输数据，如果是的话，用16KB块格式化分区也没有意义，优化它上游？ 如果我有一组非常随机的4k操作，这会触发相同数量的16KB块请求吗？ 如果任何人已经完成了这样的测试，我真的很想听到它......

Answer 1

实际的物理连接方式是通过AWS软件定义的以太网LAN。 EBS本质上是一个SAN。这些卷没有物理连接到实例，但它们物理上位于相同的可用区域内，访问是通过网络进行的。

如果实例是“EBS Optimized”，则实例和EBS之间的通信有单独的以太网带宽分配。否则，EBS也会使用处理该实例的所有IP流量的同一以太网连接。

EBS gp2卷后面的SSD是4KiB页对齐的。

请参阅AWS re:Invent 2015 | (STG403) Amazon EBS: Designing for Performance从24:15开始。

如在AWS re:Invent 2016: Deep Dive on Amazon Elastic Block Store (STG301)中所述，EBS卷不是物理卷。他们没有把你的SSD硬盘交给你。 EBS卷是一个逻辑卷，它跨越整个可用区域内的大量分布式设备。 （设备上的块也在可用区内的EBS内复制到第二个设备。）

这些因素应该明显表明，实际SSD的性能并不是EBS性能的一个特别重要的因素。无论如何，EBS会根据您为音量付费的比例分配资源......这当然与音量的大小以及您选择的功能集（音量类型）成正比。

16KiB是EBS用于为gp2建立性能基准的I/O的公称大小。它可能没有其他特别的意义，因为它似乎与EBS分配给您的卷的处理资源有关或多或少与媒体设备本身有关 - EBS卷位于拥有自己“资源”的存储群集中（CPU，内存，网络带宽等）和16KiB似乎是与EBS基础架构中某种资源分配相关的名义值。

请注意，sc1和st1卷使用非常不同的标称I/O大小：1 MiB。显然，这与物理存储设备无关，因此这可以证明gp2（和io1）的16KiB数字。

甲GP2体积可以执行到最低的几个限制：

• 160 MIB /秒，这取决于连接的实例类型‡
• 的当前数目瞬时IOPS的可用的体积，这是最高的
  • 100 IOPS不管体积大小的每
  • 3 IOPS配置的卷大小的吉布
  • IOPS在令牌桶学分可与在3000个IOPS
• 10,000 IOPS量上限不管量有多大

‡较小实例类型不能提供160MiB /秒无论如何，网络带宽。例如，r3.xlarge只有半个千兆（500 Mbps）的网络带宽，将您到EBS的总流量限制为大约62.5 MiB /秒，因此您将无法将更多吞吐量推送到EBS卷上这来自该类型的一个实例。 除非您使用的是非常大的实例或非常小的卷，否则对EBS性能的最可能的限制将是实例的限制，而不是EBS的限制。

您被限制在上面列表中的第一个（最低）阈值，标称16 KiB I/O大小的影响如下：如果您的I/O小于16KiB，则最大可能IOPS不会增加，如果他们是更大的，你的最大可能IOPS可以减少：

• 4KiB的I/O大小将不会提高性能，因为一个I/O的速率限制的目的，公称尺寸为建立16KiB，但是
• 4KiB的I/O大小不可能有意义地降低连续I/O的性能，因为对于EBS的会计目的而言，它们在内部组合在一起。因此，如果您的实例要制作4个 4个KiB顺序I/O请求，EBS很可能将其计为1个I/O无论如何
• 4KiB的I/O大小和非常随机的I/O确实不会综合起来，理论上相对于相同数量的16KiB非常随机的I/O来说，性能会很差，但本能和经验告诉我这个边界在学术和理论领域，除了极少数情况。它可能与帮助一样可能受到伤害，因为小写操作会使用相同数量的IOPS，但通过网络传输更多不必要的数据。
• 如果您的I/O大于16KiB，如果磁盘带宽达到IOPS阈值之前达到160MiB/s阈值，则最大IOPS将会降低。

最后的想法是，EBS在负载下表现最佳。也就是说，单个线程产生一系列随机I/O将不会使EBS卷的队列充满请求。如果情况并非如此，您将无法看到最大可能的表现。

有关EBS性能的更多讨论，另请参阅Amazon EBS Volume Performance on Linux Instances。