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)亚马逊EBS:从24:15左右开始设计性能.

如AWS re:Invent 2016: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
  • 每个配置的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
• I/O大小为4KiB且极其随机的I/O确实不会合并,因此理论上相对于相同数量的16KiB极随机I/O表现不佳,但本能和经验告诉我这个边界在学术和理论领域除非极少数情况下.它可能像帮助一样受到伤害,因为小写操作会使用相同数量的IOPS,但会通过线路传输更多不必要的数据.
• 如果您的I/O大于16KiB,如果在达到IOPS阈值之前磁盘带宽达到160MiB/s阈值,则最大IOPS将降低.

最后一个想法,EBS在负载下表现最佳.也就是说,制作一系列随机I/O的单个线程不会使EBS卷的队列充满请求.如果不是这种情况,您将看不到最大可能的性能.

有关EBS性能的更多讨论,另请参阅Linux实例上的Amazon EBS卷性能.