您能否指出一些有关 EBS 如何在 gp2 卷的幕后工作的资源？ 我理解它的方式，它是一项服务，但实际上它是以冗余方式将 SSD 驱动器阵列连接到实例的某种形式 实际的物理连接方法是什么？ 该文档提到数据以 16KB 或 256KB 块传输的事实，但我找不到更多关于此的信息。 例如，如果在 Linux 中，我的分区被格式化为 4KB 块，这是否意味着 EBS 将使用 16KB 块将数据传输到磁盘和从磁盘传输数据，如果是这样的话，是否也使用 16KB 块格式化分区并进行优化？它上游？ 如果我有一组非常随机的 4k 操作，这会触发相同数量的 16KB 块请求吗？ 如果有人已经做过这样的测试，我真的很想听听......
【问题讨论】：
标签： amazon-web-services amazon-ec2 amazon-ebs
实际的物理连接方式是通过 AWS 软件定义的以太网 LAN。 EBS 本质上是一个 SAN。这些卷没有物理连接到实例，但它们在物理上位于同一可用区内，访问是通过网络进行的。
如果实例是“EBS 优化型”，则会为实例和 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 会根据您为卷支付的费用分配资源……这当然与卷的大小以及您选择的功能集（卷类型）成正比。
16KiB 是 EBS 用于为 gp2 建立性能基准的 I/O 的标称大小。它可能没有其他特殊意义，因为它似乎与 EBS 分配给您的卷的处理资源和媒体设备本身一样多或更多——EBS 卷存在于拥有自己“资源”的存储集群中（CPU、内存、网络带宽等）和 16KiB 似乎是与 EBS 基础架构中某种资源分配相关的标称值。
请注意，sc1 和 st1 卷使用非常不同的标称 I/O 大小：1 MiB。显然，这与物理存储设备没有任何关系，因此这可以证明 gp2（和 io1）的 16KiB 数的结论。
gp2 卷最多可以执行几个限制中的最低值：
‡无论如何，较小的实例类型无法提供 160MiB/秒的网络带宽。例如，r3.xlarge 只有半千兆 (500 Mbps) 的网络带宽，将您到 EBS 的总流量限制在大约 62.5 MiB/秒，因此您无法将更多的吞吐量推到 EBS 卷上this 来自该类型的实例。 除非您使用非常大的实例或非常小的卷，否则 EBS 性能最可能的限制将是实例的限制，而不是 EBS 的限制。
您的上限为上述列表中的第一个（最低）阈值，标称 16 KiB I/O 大小的影响如下：如果您的 I/O 小于 16KiB，则您的最大可能 IOPS 不会增加，如果它们更大，您的最大可能 IOPS 可能会降低：
最后的想法是，EBS 在负载下表现最好。也就是说，进行一系列随机 I/O 的单个线程不会保持 EBS 卷的队列充满请求。如果不是这种情况，您将看不到最大可能的性能。
有关 EBS 性能的更多讨论，另请参阅 Amazon EBS Volume Performance on Linux Instances。
【讨论】：
dd