好的，所以我想开始比以往更多地利用我的 SAN，同时利用 ESXi。
目前，我有一个连接到单机箱 EMC AX4-5 FC 存储阵列的 Dell PowerEdge 1955 刀片阵列。我基本上将 SAN 用作 DAS。我在 SAN 上有指向特定物理机器的 LUN，这些机器将 LUN 用于任何用途（主要是数据库和 Samba/NFS 共享，具体取决于目标服务器）。
我有多个物理文件服务器，每个都有一个 samba 配置设置来提供适当的共享。由于我从来没有让 RHCS 工作，因此一次只有一个文件服务器安装了 LUN。如果文件服务器死机，我会手动隔离它（通过卸载和取消显示驱动器、使用 navisphere 实用程序或通过 DRAC 终止电源），然后使用 navisphere 实用程序在下一个竞争者上显示提供的 LUN（之后，启动 apache 和其他守护进程）。全部手动，现在。
我感觉有点像 Ferris Bueller 在吹单簧管。从来没有上过课！
无论如何，我正在努力改进。我想做的是在物理主机上安装 ESXi，然后创建 LUN 来保存两个文件服务器映像（以防一个损坏/fubar），其中一个将是活动的，另一个将是备用。至少这样，我并没有提高自动化（虽然我很快就会写一个脚本来切换“活动”服务器），但我觉得我正在增加灵活性，而且我可以使用ESXi 主机来容纳其他虚拟机，并且不会像现在一样浪费硬件。
我的问题是：
1）我的计划有多愚蠢？
2）在实际实施中，我应该在 LUN 上创建一个普通的 vmdk 映像，还是应该给它一个“原始”分区（如果 ESXi 甚至可以这样做？）
3）是否有使用非集群文件服务器的“好”方法？
你的计划并不疯狂。像往常一样，根据您要实现的目标以及如何保护数据，有多种方法可以解决此问题。
首先，您可以使用“原始设备映射”将原始 LUN 呈现给 VM。去做这个：
优点：快速设置、快速使用、简单，如果您发现自己需要 V2P，可以将磁盘表示为物理主机
缺点：您可能会丢失一些基于 VMware 的快照/回滚选项，具体取决于您使用的是物理兼容模式还是虚拟兼容模式
另一种选择是在 LUN 上创建 VMFS 以创建数据存储，然后将 VMDK 磁盘添加到位于该数据存储上的 VM。
在这两种情况下，如果 VMware 或您的 VM 在故障期间吃掉文件系统，您将处于类似的风险位置；一种并不比另一种好很多，尽管可用的恢复选项将完全不同。
除非必须，否则我不会部署 RDM；我发现它们并没有给我带来作为 VMDK 的太多灵活性（而且我一直被错误所困扰，这些错误使它们在执行其他存储操作时变得不切实际（自修复以来 - 请参阅该链接中的 RDM 部分））
至于你的虚拟机，你最好的选择是将文件服务器的启动磁盘作为 VMDK 存储在 SAN 上，以便在主机发生故障时让其他主机启动它。使用 VMware 的 HA 功能，在另一台主机上启动 VM 是自动的（VM 将在第二台主机上启动，就好像电源已被拉断一样；期望执行通常的 fsck 和魔法以将其启动，就像在普通服务器的情况下一样）。请注意，HA 是一项许可功能。
为了缓解 VM 故障，您可以构建文件服务器的轻量级克隆，其中包含启动所需的最低限度并让 SAMBA 在配置状态下启动，并将其存储在每个主机的本地磁盘上，等待您从虚拟机失败并打开电源。
在 SAN 故障的情况下，这可能会或可能不会为您购买额外的选择；最好的情况下，您的数据存储将需要 fsck 或其他修复，但至少您不必在顶部修复、重建或配置 VM。最坏的情况是，您丢失了数据并需要返回磁带……但无论如何您已经处于那种状态。
我会坚持使用 vmdk 映像，以防万一您将来转而使用 vmotion，您永远不知道您可能会为此获得预算。
如果您的机器没有集群，那么就我而言，管理它们的最佳方法是尝试尽可能均匀地分散负载。我有 3 个非集群 2950，其中来自最关键 vms 的负载尽可能为每个的 1/3。理论上我不太可能一次松开一个以上的盒子，所以至少 2/3 将能够继续运行而不受影响。
从电源的角度来看，将机器加载到尽可能接近 100% 并关闭其他机器的电源可能会更有效，但对我来说，这似乎就像把你所有的鸡蛋放在一个篮子里一样。
我不会称自己为这方面的专家，这正是我所做的。
嘿马特。使用虚拟化解决方案时，有很多方法可以分割解决方案。首先，有很多基准测试显示了原始 LUN (RDM) 与 VMDK 的性能，差异通常可以忽略不计。使用 RDM 需要注意的一些事项： 只有某些集群情况需要使用 RDM（MS 集群）。RDM 有 2TB 的限制，但 LVM 可用于解决此限制。与将 LUN 提供给 ESXi 以用于 VMFS 并将 vmdk 放在其上相比，RDM 更难跟踪。VMDK（如前所述）有一些不错的好处：svMotion、快照（不能对 pRDM 进行快照）。
如果运行 Free ESXi，我可能会这样处理您的情况。首先，所有数据都在 VMFS LUN 上的 vmdk 文件中。设置 2 个 VM 并使用 Heartbeat 进行 IP 和服务的故障转移。Heartbeat 将转移服务 IP，并且可以处理脚本以在适当的位置卸载/装载数据 LUN。您甚至可以编写一些 VMware Remote CLI 脚本，以确保关闭“关闭”的虚拟机以进行隔离。使用心跳直接在系统之间协调访问数据lun/运行相同服务的风险应该非常低。这里的关键是确保数据 LUN 的挂载/卸载和服务的启动/关闭由 Heartbeat 处理，而不是正常的 init 机制。
另一种故障转移可能通过监控系统来完成。当它检测到主机宕机时，它可以使用 VMware Remote CLI 发出关闭电源（为了安全起见），然后打开备份虚拟机的电源。在这种情况下，故障回复是相当手动的。
在我的“小”环境中，我没有看到 VMDK 被损坏。我还意识到，如果您有超过 2 台 ESX(i) 主机或十几台虚拟机，您将需要 vCenter 来帮助跟踪所有内容。考虑到这些好处，一些 Essential/Plus 套餐的成本并不高。
马特，你知道我不使用 VMware，但我一直在 Xen 中使用“RAW”。仅使用少量负载较轻的虚拟机，我怀疑您会看到很大的性能差异。但是当你开始接触越来越多的来宾时，如果所有这些来宾都在同一个文件系统上，你最终会遇到队列深度问题。对于 NFS 支持的存储尤其如此。NFS 服务器没有那么多问题，但大多数 NFS 客户端实现都很糟糕。
如果您正在寻找冗余（san 故障），我不知道同步 vmdks 的好方法。但是如果你使用块设备，你仍然可以使用 DRBD 来复制你想要/需要复制的虚拟机。
我认为您应该问自己“我是否打算回到物理服务器”
如果答案是可能，那么也许您应该坚持使用 RDM。带有 RDM 的 ESXi（我认为）需要您购买一些东西才能使您的光纤正常工作（在 esxi 上也不是 100% 确定）。
我们有几台机器，我刚刚使用 RDM 从物理服务器快速迁移到 ESX (4.0)。我混合了 Linux 和 Windows 机器（这两个平台都超级简单）。我们仍然有一些在物理服务器上运行的旧版 FreeBSD（6.0 和更早版本）我们不能使用 RDM，因为旧的 FBSD 内核不支持这一点。它很快，除了指向我的 LUN 并安装 VMWare 工具外，我什么也不做。脑死简单..没有转换器没有大惊小怪......
您应该问自己的另一件事是“我想使用 VMWare 的哪些功能？”
根据您对此的回答，除了 VMDK，您可能别无选择。例如，如果您将 SAN 用于快照，并且不关心为此使用 vmware。
一些笔记我将与您分享到目前为止我们遇到的问题。Vmotion 与 RDM 和 VMDK 一样好用，另一方面，Storage Vmotion 仅适用于非 RDM，尝试使用 Vmotion 存储从 RDM 到 VMDK 很糟糕只需使用转换器.. 大多数 Linux 发行版都有一个开源 vmware 工具包，这使得安装工具不是问题。备份应用程序工作得非常好，并且不受 vmware 的影响，但并没有像我们希望的那样做很多事情。我强烈建议从 vmware 上一堂课。我花了一周时间，值得每一分钱 VMWare 支持真是太棒了。如果您获得支持合同并且必须打电话给他们，那么他们是一流的.. 找到可以帮助我的人（对于许多菜单.. )，但是一旦我得到它们，它们总是会得到快速可靠的支持。