NetApp SE 实验室报告：SAN Boot with VMware ESX 3.0.0
本文转自: [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 引导要求（单击放大）
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 主机在存储控制器容错测试过程中的可靠性现在也非常坚固。