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页面对齐的。

为此，请参阅24:15左右的AWS re:Invent 2015 | (STG403) Amazon EBS: Designing for Performance。

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

这些因素应该表明，实际SSD的性能并不是EBS性能的一个特别重要的因素。从各方面来看，EBS按照您为音量支付的比例分配资源......这当然与音量大小以及您选择的特征集（音量类型）成正比。 / p>

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，无论音量大小
  • 每个配置的GiB卷大小为3 IOPS
  • 您的令牌桶中可用的IOPS积分，上限为3,000 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可能会降低：

• I / O大小为4KiB不会提高性能，因为用于速率限制的I / O标称大小为16KiB，但是
• I / O大小4KiB不太可能通过顺序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。