好吧，所以我想开始比以前更多地利用我的 SAN，同时利用 ESXi。
目前，我有一个 Dell PowerEdge 1955 刀片阵列，连接到一个单机箱 EMC AX4-5 FC 存储阵列。我基本上将 SAN 用作 DAS。我在 SAN 上拥有指向特定物理机器的 LUN，这些机器将 LUN 用于各种用途（主要是数据库和 Samba/NFS 共享，具体取决于目标服务器）。
我有多个物理文件服务器，每个服务器都有一个 samba 配置设置来提供相应的共享。由于我从未让 RHCS 工作，因此一次只有一个文件服务器挂载了 LUN。如果某个文件服务器死机，我会手动隔离它（通过卸载和取消显示驱动器、使用 navisphere 实用程序或通过 DRAC 关闭电源），然后使用 navisphere 实用程序在下一个竞争者上启动显示的 LUN（之后，启动 apache 和其他守护进程）。现在全部手动完成。
我感觉自己有点像 Ferris Bueller 吹单簧管。从来没有上过课！
无论如何，我正在努力改进。我想要做的是在物理主机上安装 ESXi，然后创建 LUN 来保存两个文件服务器映像（以防其中一个损坏/出问题），其中一个将是活动的，另一个将是备用的。至少这样，我不会改进自动化（尽管我很快就会开始编写一个脚本来切换“活动”服务器），但我觉得我增加了灵活性，而且我可以使用 ESXi 主机来保存其他虚拟机，而且不会像现在这样浪费硬件。
我的问题是：
1）我的计划有多愚蠢？
2）在实际实施时，我应该在 LUN 上创建一个普通的 vmdk 映像，还是应该给它一个“原始”分区（如果 ESXi 可以实现的话？）
3）有没有使用非集群文件服务器的“好”方法？
答案1
你的计划并不疯狂。像往常一样，根据你想要实现的目标和保护数据的方式，有多种方法可以解决这个问题。
首先，您可以使用“原始设备映射”将原始 LUN 呈现给 VM。具体操作如下：
- 将 LUN 呈现给 ESXi 主机（或主机组，如果您要使用集群/HA）
- 向您的虚拟机添加磁盘，选择原始设备映射，指向 LUN
- 重新扫描虚拟机内的 SCSI 总线
- fdisk，挂载并添加到fstab，就像普通磁盘一样。
优点：设置快捷，使用快捷，简单，如果您以后需要 V2P，可以将磁盘表示到物理主机
缺点：您可能会丢失一些基于 VMware 的快照/回滚选项，具体取决于您使用物理还是虚拟兼容模式
另一种选择是在 LUN 上创建 VMFS 来创建数据存储，然后将 VMDK 磁盘添加到该数据存储上的 VM。
- 优点：如果您购买了使用许可，它对 Storage vMotion 很友好。这允许在 LUN 甚至 SAN 之间热迁移 VMDK 磁盘。
在这两种情况下，如果 VMware 或您的 VM 在发生故障期间占用了文件系统，那么您面临的风险就相似；虽然可用的恢复选项会有很大不同，但其中一种并不会比另一种好很多。
除非迫不得已，否则我不会部署 RDM；我发现它们并没有给我带来像 VMDK 那样的灵活性（而且我已经被错误这使得它们在执行其他存储操作时不切实际（已修复 - 请参阅该链接中的 RDM 部分）
至于您的虚拟机，实现灵活性的最佳方法是将文件服务器的启动盘作为 VMDK 存储在 SAN 上，这样当主机发生故障时，其他主机就可以启动它。使用 VMware 的 HA 功能，在另一台主机上启动您的虚拟机是自动的（虚拟机将在第二台主机上启动，就像断电一样；需要像在普通服务器的情况下一样执行通常的 fsck 和 magic 来启动它）。请注意，HA 是一项许可功能。
为了缓解虚拟机故障，您可以构建文件服务器的轻量级克隆，其中包含启动所需的最低限度，并让 SAMBA 以配置状态启动并将其存储在每个主机的本地磁盘上，等待您从故障虚拟机添加数据驱动器并启动它。
在 SAN 发生故障时，这可能会或可能不会为您带来额外的选择；最好的情况是，您的数据存储将需要 fsck 或其他修复，但至少您不必修复、重建或配置虚拟机。最坏的情况是，您丢失了数据，需要返回磁带……但无论如何，您已经处于那种状态。
答案2
我会坚持使用 vmdk 图像，以防您将来转而使用 vmotion，您永远不知道您可能会为此获得预算。
如果您的机器不是集群的，那么就我而言，管理它们的最佳方法是尝试尽可能均匀地分散负载。我有 3 个非集群的 2950，其中最关键的虚拟机的负载尽可能在每个虚拟机上占 1/3。理论上，我不太可能一次丢失多个盒子，因此至少 2/3 将能够继续运行而不受影响。
从功率角度来看，将机器的负载尽可能达到接近 100% 并关闭其他机器可能会更有效率，但在我看来，这似乎是把所有的鸡蛋都放在一个篮子里。
我不会称自己为这方面的专家，这只是我所做的事情。
答案3
嘿，Matt。使用虚拟化解决方案时，有很多方法可以分割解决方案。首先，有很多基准测试显示原始 LUN (RDM) 与 VMDK 性能，并且差异通常可以忽略不计。使用 RDM 时需要注意以下几点：只有某些集群情况才需要使用 RDM（MS 集群）。RDM 有 2TB 的限制，但可以使用 LVM 来解决此限制。与将 LUN 提供给 ESXi 用于 VMFS 并在其上放置 vmdk 相比，RDM 更难跟踪。VMDK（如上所述）有一些不错的优势：svMotion、快照（无法快照 pRDM）。
如果运行的是 Free ESXi，以下是我可能如何处理您的情况。首先，所有数据都在 VMFS LUNS 上的 vmdk 文件中。设置 2 个 VM 并使用 Heartbeat 进行 IP 和服务故障转移。Heartbeat 将转移服务 IP，并可以在适当的情况下处理脚本以卸载/安装数据 LUN。您甚至可以编写一些 VMware Remote CLI 脚本，以确保“关闭”的 VM 因隔离而关闭。通过 heartbeat 直接协调系统，访问数据 LUN/运行相同服务的风险应该非常低。这里的关键是确保数据 LUN 的安装/卸载和服务的启动/关闭由 Heartbeat 处理，而不是正常的初始化机制。
另一种故障转移方式是通过监控系统实现的。当它检测到主机宕机时，它可以使用 VMware Remote CLI 发出关闭电源（以保证安全）然后打开备份虚拟机的电源。在这种情况下，故障恢复相当手动。
在我的“微型”环境中，我从未见过 VMDK 损坏。我还意识到，如果您有超过 2 个 ESX(i) 主机或十几个 VM，您将需要使用 vCenter 来帮助跟踪所有内容。考虑到其优势，一些 Essential/Plus 软件包的价格并不太贵。
答案4
我认为你应该问自己“我是否打算回到物理服务器”
如果答案是“可能”，那么也许您应该坚持使用 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 的支持非常棒。如果您获得支持合同并必须打电话，他们是一流的。我很沮丧找不到可以帮助我的人（太多菜单。。），但是一旦我找到他们，他们总是提供快速可靠的支持。