本文轉自: [url]http://www-cn.netapp.com/news/techontap/2006/oct/1006tot_labreport.htm[/url] Nick Triantos 著 擁有大量服務器的企業正逐漸轉向無磁盤服務器，可以從 SAN (FC 或 IP) 引導，從而減少成本、合并存儲并優化供應。盡管 SAN 引導不是新技術，刀片式服務器的引入可以有助于加速它的采用。刀片式服務器提供更好的可管理性、減少了硬盤成本并簡化了電纜管理，以及節省了電能、冷卻和×××成本。 從 SAN 引導的最常用平臺之一是 VMware ESX 服務器。越來越多的企業正部署 VMware ESX 服務，以將許許多多的物理服務器合并到單刀片機箱中少量的無磁盤刀片式服務器中。其它的企業已著手使用單獨的 1U 基于 Intel 的服務器部署 VMware。 已知現在的大多數服務器都附帶內部 SATA 驅動器（不支持其托管 ESX 服務器影像），SAN 引導成為最具吸引力的選擇。基于存儲的快照、克隆和復制技術提供附加的優勢，可以快速從克隆或快照來恢復損壞的 ESX 圖像，并將其存儲在相同的物理服務器上或將其復制到遠程站點作為 DR 用途。
比較
ESX Server 2.5.x 和 3.0.x
的 SAN 引導要求（單擊放大） 與大多數技術供應商一樣，Network Appliance 在其大量的主要銷售辦公室都有實驗室。這些實驗室主要用于技術演示，并利用各種操作系統和第三方軟件。NetApp 達拉斯辦公室也有一個系統工程實驗室，NetApp SE 可以深入鉆研特定的技術。自從 2.5.1 發布以來，此實驗室包括了 VMware ESX 服務器環境，而自從 2.5.3 發布以來我們已經從光纖引導 ESX 服務器。 八月份，我決定升級到新的 ESX 3.0.0 版本來了解一下變化，立即被其結果完全吸引。 使用 ESX 3.0.0，VMware 在支持從 SAN 引導方面取得了重大的進步。簡化了以前版本的多種要求。根據我的體驗，安裝過程快速而簡單并且 — 至少在測試目的方面 — 環境可以完美地運行。

設置 ESX 3.0.0 for SAN Boot

設置附帶 NetApp 存儲的 VMware for SAN boot 非常容易。整個過程不超過 20 或 25 分鐘，從提供引導 LUN 時間到 ESX 影像安裝完成的時間。 下表顯示我們的設置。

服務器	IBM x346
CPU	2x Xeon 3.2GHz
內存	8GB
FC HBA	2x QLA 2340
FC 交換機	MDS 9120
外部存儲	NetApp FAS3050c
表 1.NetApp SE 實驗室設置

安裝之后，開始創建虛擬機 (VM) 并安裝客機操作系統。我選擇用 iSCSI 在 LUN 上安裝 VM，以便可以了解 VMware 的實施。配置 iSCSI initiator 非常簡單，可以毫無問題地安裝客機操作系統。已知當前 ESX 不提供 iSCSI LUN 的多路徑機制，我選擇實施 NIC 隊列，本質上用作相同的目的。

對默認 ESX 3.0.0 的建議編輯。配置

當前實驗室環境的屏幕快照
（單擊放大） 如果對 SAN boot with ESX 3.0.0 感興趣，則需要考慮一些問題。首先，建議在做出購買任何 HBA 的決定之前，先聯系存儲供應商，認真地查看 VMware ESX Server 3.0 的 I/O 兼容性指南。會發現某些型號的 HBA 不支持 SAN 引導。 此外，需要作出許多調整優化和自定義才能達到更高的性能，并在硬件故障時不會發生中斷容錯。建議對默認的 ESX Server 3.0.0 設置進行三個簡單的更改：

• 僅在 1 HBA 上啟用 BIOS。
• 修改執行調節/隊列深度。
• 修改 PortDownRetryCount 參數。

在以下章節對每一點都進行了詳細描述。但是，請牢記此設備沒有經過完全測試或經過 NetApp 工程的批準，因此不斷定它是所有環境的正確答案。

技巧 #1：僅在 1 HBA上啟用 BIOS。

僅在用于引導的原始 HBA、電纜或 FC 開關失效而需要重新啟動服務器時，才在第 2 個 HBA 上啟用 BIOS。在此情況下，可以使用 QLogic Fast!UTIL 選擇活動的 HBA、啟用 BIOS、掃描 BUS，以此來查找引導 LUN 并將 WWPN 和 LUN ID 分配給活動的 HBA。但是，兩個 HBA 連接都作用時，僅有一個連接需要啟用 BIOS。

技巧 #2：修改執行調節/隊列深度。

執行調節/隊列深度表示可以在任何一個 HBA 端口執行的顯著命令的最大數目。ESX 3.0.0 默認為 32，但是環境的最佳值取決于以下兩個因素：

• 通過陣列目標端口暴露的 LUN 總數目
• 陣列目標端口隊列深度

確定該值的公式是：

隊列深度 = 目標隊列深度 / 從陣列映射的 LUN 總數目

此公式將保證每個 LUN 上并行的快速加載不會充斥目標端口，造成 QFULL 情形。QFULL 情形表示目標端口不能處理能力以外的 I/O。在大多數操作系統中，接收到目標的 QFULL 情形之后，HBA 驅動器通常將 LUN 的最大隊列深度減小到最小值，通常為“1”，從而將 I/O 隊列調節到目標端口。當目標停止發出 QFULL 情形時，HBA 驅動器將開始逐漸增加 LUN 隊列深度值，從而緩慢地將 I/O 增加到目標端口。 下面是一個示例，說明以上公式如何有助于避免 QFULL 情形。如果目標端口具有 1024 的隊列深度并且通過該端口暴露 64 LUN，則每個主機上的隊列深度設置為每 LUN 16 個顯著 I/O。這是最安全的方案，保證不會出現 QFULL 情形：

每 LUN 16 個顯著 I/O x 64 LUN = 目標端口隊列深度

但是請注意。如果使用以上公式單獨計算每個主機的隊列深度，則仍有出現 QFULL 情形的可能。 原因如下。現在詳述以前的示例，并假定共有 64 LUN 和四個 ESX 主機，每個主機映射 16 LUN。 對每個 ESX 主機單獨進行計算得出：隊列深度 = 1024 / 16 LUN = 每 LUN 64 個顯著 I/O。但是，在四個 ESX 服務器中全部 64 LUN 上同時快速加載將得出：每 LUN 64 個顯著 I/O x 64 LUN = 4096，比物理陣列目標端口的隊列深度大得多。這是一種不合要求的情形，在特定條件下將生成 QFULL 并調節 I/O。

要改變 QLogic HBA 上的隊列深度

?

請創建 /etc/vmware/esx.conf 副本。

查找每個 HBA 的以下條目：
/device/002:02.0/name = "QLogic Corp QLA231x/2340 (rev 02)"
/device/002:02.0/options = ""

c) 按如下所示修改：
/device/002:02.0/name = "QLogic Corp QLA231x/2340 (rev 02)"
/device/002:02.0/options = "ql2xmaxqdepth= xxx"
，其中 xxx 為隊列深度值。

重新啟動。

技巧 #3：修改 PortDownRetryCount 參數。

PortDownRetryCount 參數值必須設置為存儲供應商推薦的值，使用 Fast!UTIL。此設置指定適配器驅動程序向返回端口故障 (Port Down) 狀態的端口發出重試命令的次數。此值對于 ESX 服務器是 2* n +5，其中 n 是 HBA BIOS 中的 PortDownRetryCount 的值。 可以在 HBA 中直接更改此值，也可以在安裝 ESX 之后通過編輯 /etc/vmware/esx.conf 文件更改此值。要編輯該文件，請查找正使用的 HBA 模型下的“options=”條目，進行以下更改。

要更改 PortDownRetryCount 參數

?

請創建 /etc/vmware/esx.conf 副本。

查找每個 HBA 的以下條目：
/device/002:02.0/name = "QLogic Corp QLA231x/2340 (rev 02)"
/device/002:02.0/options = ""

按如下所示修改：
/device/002:02.0/name = "QLogic Corp QLA231x/2340 (rev 02)"
/device/002:02.0/options = "qlport_down_retry= xxx"
，其中 xxx 為存儲供應商推薦的值。Emulex HBAs 的等效設置為“lpfc_nodedev_tmo”。默認值為“30”。

重新啟動。

總體評估

到目前為止，我使用 SAN 引導 VMware ESX 3.0.0 只有好的體驗。從程序上來看，過程當然比以前版本要簡單得多。此外，我發現 ESX 主機在存儲控制器容錯測試過程中的可靠性現在也非常堅固。

轉載于:https://blog.51cto.com/virtualman/34970

總結

以上是生活随笔為你收集整理的NetApp SE 实验室报告：SAN Boot with VMware ESX 3.0.0的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。