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。