Azure NetApp Files 的效能常見問題集
本文回答關於 Azure NetApp Files 效能的常見問題集 (FAQ)。
我該怎麼做才能最佳化或調整 Azure NetApp Files 效能？
您可以根據效能需求採取下列動作：
- 確定虛擬機器 (VM) 的大小適當。
- 為 VM 啟用加速網路。
- 選取容量集區所需的服務層級和大小。
- 為容量和效能建立具有所需配額大小的磁碟區。
無需為 Azure NetApp 檔案的專用子網路中的網路介面卡 (NIC) 設定加速網路。 加速網路是一項僅適用於 Azure VM 的功能。 Azure NetApp Files NIC 會依設計最佳化。
如何監視 Azure NetApp Files 磁碟區效能
可以透過可用計量來監視 Azure NetApp Files 磁碟區的效能。
如何將 Azure NetApp Files 的輸送量型服務等級轉換為每秒的輸入/輸出作業數 (IOPS)？
您可以使用以下公式將每秒的兆位元組數 (MBps) 轉換為 IOPS：
IOPS = (MBps Throughput / KB per IO) * 1024
如何變更磁碟區的服務等級？
您可以將現有磁碟區移至另一個使用您所需磁碟區服務等級的容量集區，以變更該磁碟區的服務等級。 請參閱動態變更磁碟區的服務等級。
如何監視 Azure NetApp Files 效能？
Azure NetApp Files 會提供磁碟區效能計量。 您也可以使用 Azure 監視器來監視 Azure NetApp Files 的使用計量。 如需 Azure NetApp Files 的效能計量清單，請參閱 Azure NetApp Files 的計量。
為什麼 IOPS 較低時工作負載的延遲較高？
在沒有其他徵兆 (例如錯誤、網路問題或應用程式不回應) 的情況下，低 IOP 工作負載通常不是問題。 低 IOPS 通常低於 500-600 IOPS，但可能會有所不同。
Azure NetApp Files 會在要求傳入時回應要求。 要求較少的工作負載可能看起來較高，但回應符合預期。 低 IOPS 工作負載 (例如 5 IOPS 和 32 KiB/秒)：
- 不在 RAM 快取中，因此需要更多地從磁碟讀取。
- 樣本量不大，因此被認為在統計上不相關。
- 樣本數不足，無法平均消除任何異常值。
由於延遲平均偏差，報告的延遲可能達到數秒甚至數十秒的範圍。 增加 IOPS 較低的磁碟區的工作負載，可以進一步幫助確定延遲偏差是否是延遲顯示數字過高的原因。
Kerberos 對 NFSv4.1 的效能影響為何？
若要了解 NFSv4.1 的安全性選項、測試的效能向量，以及預期的效能影響，請參閱 NFSv4.1 磁碟區上的 Kerberos 效能影響。
搭配 Kerberos 使用 nconnect 的效能影響為何？
不建議同時使用 nconnect 和 sec=krb5* 掛接選項。 已發現這兩個選項並用時效能會降低。
一般安全性標準應用程式開發介面 (GSS-API) 有辦法讓應用程式保護傳送至對等應用程式的資料。 此資料可能從一部機器上的用戶端傳送到另一部機器上的伺服器。
在 Linux 中使用 nconnect 時，特定伺服器的所有 nconnect 連線之間會共用 GSS 安全性內容。 TCP 是可靠的傳輸，支援失序的封包傳遞，可使用一段滑動時間範圍的序號來處理 GSS 串流中失序的封包。 收到不在序列時間範圍內的封包時會捨棄安全性內容，並議定新的安全性內容。 在現已捨棄的內容中傳送的所有訊息都不再有效，因此需要再次傳送訊息。 如果 nconnect 設定中有大量封包，則會造成封包經常超出時間範圍，而引起上述行為。 無法具體指出此行為造成的惡化比例。
Azure NetApp Files 是否支援 SMB Direct？
否，Azure NetApp Files 不支援 SMB Direct。
Azure 是否支援 NIC Teaming？
Azure 不支援 NIC 組合。 雖然 Azure 虛擬機器支援多個網路介面，但其代表邏輯而非實體建構。 因此，不會提供容錯。 此外，Azure 虛擬機器的可用頻寬會針對機器本身計算，而不是針對任何個別的網路介面。
是否支援 Jumbo 框架？
Azure 虛擬機器不支援 Jumbo 框架。