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

設(shè)置 ESX 3.0.0 for SAN Boot

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

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

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

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

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

• 僅在 1 HBA 上啟用 BIOS。
• 修改執(zhí)行調(diào)節(jié)/隊列深度。
• 修改 PortDownRetryCount 參數(shù)。

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

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

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

技巧 #2：修改執(zhí)行調(diào)節(jié)/隊列深度。

執(zhí)行調(diào)節(jié)/隊列深度表示可以在任何一個 HBA 端口執(zhí)行的顯著命令的最大數(shù)目。ESX 3.0.0 默認為 32，但是環(huán)境的最佳值取決于以下兩個因素：

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

確定該值的公式是：

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

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

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

但是請注意。如果使用以上公式單獨計算每個主機的隊列深度，則仍有出現(xiàn) QFULL 情形的可能。 原因如下。現(xiàn)在詳述以前的示例，并假定共有 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 并調(diào)節(jié) I/O。

要改變 QLogic HBA 上的隊列深度

?

請創(chuàng)建 /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 參數(shù)。

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

要更改 PortDownRetryCount 參數(shù)

?

請創(chuàng)建 /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 的等效設(shè)置為“l(fā)pfc_nodedev_tmo”。默認值為“30”。

重新啟動。

總體評估

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

轉(zhuǎn)載于:https://blog.51cto.com/virtualman/34970

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。