PowerStore：評估儲存陣列效能的有效技術

注意：只有在一切都是根據 PowerStore 最佳實務進行設定，而且沒有連線或組態問題的情況下，基準測試才有效。否則，測試可能會產生不相關的資料。

• 使用類似於實際工作負載/環境的變數進行測試。請記住，大多數工具都是模擬器，永遠無法實現類比的真實生產工作負載的 100%。
• 如果工作負載範圍很廣，請考慮使用不同的區塊大小和存取模式對讀/寫測試執行多次迭代。
• 使用多線程和異步操作或測試來確保並行或併發性能功能，並確保正在執行整體聚合輸送量潛力。 
• 請考慮並審查正在接受評估之設備的業界標準基準，因為其與貴企業的生產工作負載相關。
• 避免針對空白或空間使用率較低的檔案系統和/或磁碟區進行測試。如果未在寫入工作負載上預分配空間，則可能會發現由於測試期間動態分配空間而導致的延遲。
• 請不要忘記測試讀取 I/O，因為在大多數環境中，這通常是兩者中主要的這一個。在測試期間，請注意網路基礎結構中的封包/訊框遺失情況。
• 確認您要測試多個裝置，以模擬包含許多主機或用戶端的一般環境。舉例來說，在 PowerStore 上，一個好的數字是 16 個磁碟區。卷計數通常與使用的主機或用戶端（物理或虛擬）數量匹配;這是實現併發性的地方。

 

基準測試工具和模擬器
請記住，大多數工具都是模擬器，可能永遠無法 100% 模擬真實生產工作負載。這些基準測試工具可用於瞭解在某些情況下，效能可能、應該或將如何發展。Dell 並非這些工具的擁有者，亦不對任何與之相關的問題或問題負責。

對於任何性能測試情況，請確保使用具有異步和多線程功能的工具。這些工具的範例包括：

• 彈性 I/O 測試儀 (FIO)
• IOmeter
• Vdbench（需要 Oracle 帳戶）
• NFSometer  (僅限 Fedora/NFS)
• Intel 的 NAS 效能檢查清單

 

避免執行以下類型的測試：

• 複製和貼上
• 拖放
• 將單一檔案系統備份至磁碟
• DD 測試
• Rlarge
• Wlarge
• Mkfile
• 解壓縮、解壓縮和壓縮

在大多數基準測試情況中，有某些事項需要注意。本節無法替代瞭解工作負載大小和特性。但是，如果您缺乏過去的資料，且需要粗略估計應用程式的行為，以針對 PowerStore 的功能 (而非特定工作負載效能) 進行基準測試，請考慮下列因素：

 

 

IODepth （佇列深度）
IO深度較低 （或不夠高） 可能會限制潛在輸送量，視情況而定。因此，請一律驗證 IOdepth 是否足夠高，以反映或模擬工作負載的並行需求。IOdepth 過低可能無法正確使用裝置以充分發揮其潛能。此外，也請注意 IOdepth 過高的情形，這可能會導致裝置上出現大量佇列，並視裝置的服務時間而定，回應時間可能會更長。這可以反映重載系統的外觀。

在此測試中，當 IOdepth 為 1 時，與更真實的事物（如 64）的 IOdepth 相比，數字明顯較低。請記住，這是全快閃記憶體陣列，因此這個概念以極端但越來越常見的形式出現。

IOdepth=1“ 測試的平均每秒輸入和輸出作業 （IOPS） 約為 ~30,000。

 

經過測試，「IOdepth=64」約為平均 ~107,000 IOPS。

 

 

經過測試，「IOdepth=256」約為平均 ~142,000 IOPS。

 

 

如前所述，在大多數組態中，效能會在達到一定的 IOdepth 時處趨平穩。這裡的佇列深度為 512，而 IOdepth=64 時的 IOPS 僅略有增加。

經過測試，「IOdepth=512」約為平均 ~146,000 IOPS。

 

 


非同步與同步
使用了兩種主要的不同引擎。最受歡迎，也是迄今為止效能效率最高的是「非同步 I/O」。同步 I/O 是效率較低且效能較差的引擎類型，通常會用於具有嚴格資料完整性和保證要求的應用程式。同步 I/O 也可以在近乎零損失回復點 (RPO) 複製技術中找到。在效能測試和基準測試中，從主機的角度來看，非同步表示不需要確認單一 I/O 即可要求下一個 I/O。在同步工作負載中，需要先確認下一個 I/O，才能發出下一個 I/O，並且每個後續要求的 I/O 都需要確認 (ACK)。因此，同步 I/O 的佇列通常為 1 或更少，並且永遠不會充分利用資源。將同步操作與低線程計數或單個線程計數耦合可能會嚴重限制性能潛力，因此請始終驗證是否正在執行異步測試，如果使用同步測試，請確保使用多個線程，除非應用程式環境明確指出不要這樣做。

非同步 （Libaio - Linux 原生非同步） = 1 個執行緒



同步 （同步 I/O）：  

 

 

執行緒數
線程很重要。測試應始終使用多個線程完成，尤其是在同步測試/工作負載中。這是嘗試根據企業應用程式進程的行為類比作業/測試的多次反覆運算。多個執行緒耦合並行活動是達成系統彙總輸送量的地方。大多數異步引擎使用多個線程，因此您不必擔心線程計數。如果在同步工作負載期間沒有足夠的線程，您可能會嚴重限制針對系統的負載測試的總潛在輸送量。

多線程“表示多個線程並行工作。例如，如果您的單個設備可以在同步工作負載中為 1000 IOPS 提供服務，則在沒有佇列的情況下，設備的回應時間為 1 毫秒（因此沒有佇列，則服務時間和回應時間應該是同義詞）。顯然，回應時間為 1 毫秒的設備可以執行比 1000 IOPS 更多的工作，這是通過堆疊多個線程或相同工作負載的並行流來實現的。因此，如果將線程（或“執行此特定工作的東西”）增加到 10，則現在有 10 個單獨的線程在 1 毫秒內對設備執行 I/O。每個工作負荷執行緒仍會取得 1 毫秒，這表示每個執行緒仍僅能達到 1000 IOPS，但是這多個執行緒所執行的整個「程序」或「工作」卻可達到 10,000 IOPS。

有些工具和工作負載可以通過單個線程充分達到設備的極限，但有些工具和工作負載需要更多。總之，在類比同步負載時，您希望擁有盡可能多的線程/工作線程/流，而不會影響整體響應時間。有時增加執行緒計數不會產生正面效果 （當裝置忙碌 100% 時）。通常，對於非同步工作負載，預設會處理執行緒計數。例如，對於異步工作負載，您仍然可以在下面看到 1 個線程和 10 個線程之間的差異，儘管差異不大。由此可知，使用非同步工作負載，您就不必過度擔心執行緒的問題。

此處的單一執行緒可以使用「libaio」(非同步) 引擎達到 68,000 個 IOPS。 

 

如果您將執行緒 （numjobs） 增加到 10，您仍會看到 IOPS 增加。

 

再談到同步工作負載，雖然這是一個極端情況，但仍有兩個主要因素使這個測試成為一個不好的測試，即同步性質。 

傳送 I/O-1，等待 ACK，傳送 I/O-2，等待 ACK，依此類推

 並且無法出於相同的目的堆疊多個執行緒。 

job1=send I/O-1 - job2=send I/O-1 - job3=send I/O-1.....job1=get ack， send i/O-2 - job2=get ack， send i/O-2 - job3= get ack， send i/O-2 依此類推

直接旗標

對於某些工具，尤其是 *nix 型工具/OS，您可能會看到「直接 I/O」的選項。這可以與「非同步」引擎一起使用，且不應與「同步」I/O 混淆。在某些未指定此旗標的工具中，您可能會寫入伺服器快取，而不是直接寫入磁碟。主機要做的是繞過自己的快取並直接寫入磁碟。這是測試儲存裝置時的重要因素。當您設定了「直接」旗標時，從技術上來講，您是在寫入磁碟，儘管在這種情況下，「磁碟」實際上是儲存快取。出於測試目的，這仍然是可以接受的，因為即使使用正確的工作負載，您仍然在類比和準確類比此工作負載在實際環境中的行為方式，因為生產負載也會在發送回確認之前命中緩存。（不要僅僅因為您涉及緩存的性能數位而不僅僅是後端心軸而感到受騙。

 

頻寬 （MB/秒） 與輸送量 （IOPS）

您可以針對兩個主要的方面進行測試。網路和效能領域的輸送量通常是指資料傳輸，但在 SAN/區塊環境中，通常會使用「輸送量」來表示 IOPS。因此，必須首先瞭解要測試的工作負荷特徵。

帶寬 （MB/s） - 帶寬是可以在管道或系統上一次（或在 X 間隔內，通常為“每秒”）容納的數據度量。這表示它正在測量您在一段時間內傳輸的資料量。雖然頻寬和 IOPS 並不相互排斥，但您可以使用相同的 IOPS 量得到更高或更低的頻寬數字，但這完全取決於區塊大小。請記住，您不是用頻寬來測量速度，速度是完全不同的東西，雖然它確實會影響頻寬，但通常是您在高頻寬工作負載下無法控制的因素。因此，如果測試頻寬，請始終使用較大的塊（在合理範圍內），以便每個 I/O 的數據比測試 IOPS 的數據大，因為較大的塊自然需要更長的服務時間。例如，如果您想要達到 1 MB/s，但您使用的是 8 KB 的區塊大小，則必須推動大約 125 個 IOPS 才能達成此目的。但是，如果您使用 512 KB 區塊，則只需要兩 （2） 個 IOPS。
（如果您要保持 125 IOPS，並且仍然將塊大小從 8 KB 增加到 512 KB，那麼您現在正在推動 64 MB/s！

但是，由於單個 I/O 中有更多數據，因此通常需要更長的時間來“打包”該 I/O（查找、串在一起等）。因此，服務時間自然會更長。有時您的佇列較小，因此您的回應時間雖然自然更高，但應該相當接近。請記住，雖然回應時間確實會影響您可以達到的頻寬，但每個 I/O 資料量的增加通常會稍微超過每個該 I/O 類型的回應時間 (RT)。由於回應時間較長，因此您不希望大型塊工作負載必須是隨機的。因此，頻寬工作負載往往是連續的。當您為大型塊工作負載引入隨機性質時，穩定的數據傳輸速率始終受到中斷，並且您開始感受到每個 I/O 的回應時間略高的影響。

輸送量 （IOPS） - 輸送量/IOPS 是小型區塊工作負載最常見的觀點，尤其是當它們變得更加隨機時。任何超過 32 KB-64 KB 的內容都可以視為一個大區塊。對於輸送量，上述因素最為重要 (如執行緒計數、同步或非同步、佇列深度等)。在這裡，您嘗試測量的不是在 X 間隔內可以傳輸的整體資料量，而是承載您嘗試服務的資料 (每 x 間隔) 的個別套裝 (I/O 要求) 的數量。像 OLTP (銀行業) 這樣的環境不太關心他們可以傳輸多少資料，因為它們的資料佔用空間通常很小。但是，這些小型資料集可能會很忙碌，而且通常會很忙碌。這些資料集具有高偏差性 (參考少量空間，但變化很大且不斷變化)。小型資料封裝通常僅包含使用數字或較小字串值更改/更新區塊的要求，因此不需要大型 I/O 封裝。但是，由於交易的性質以及交易的數量如此龐大，我們希望驗證我們是否能夠跟上每個單獨的要求。通常，區塊大小越小，在指定情境下可以達成的 IOPS 就越多，儘管小區塊工作負載主要與隨機存取相關聯，但使用小區塊循序工作負載可以達成更高的輸送量。然而，小區塊循序工作負載是專用的，並不普遍，因此請僅在環境需要時測試這些情境。