将服务器虚拟化到SAN的最佳做法？

好了，所以我想比以往更多地利用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主机可容纳其他VM，并且不会像现在这样浪费硬件。

我的问题是：

1）我的计划有多愚蠢？

2）关于实际实现，我应该在LUN上创建普通的vmdk映像，还是应该给它一个“原始”分区（如果在ESXi中甚至可以做到这一点？）

3）是否有使用非群集文件服务器的“好”方式？

您的计划并不疯狂。像往常一样，有多种方法可以根据您要实现的目标以及如何保护数据进行攻击。

首先，您可以使用“原始设备映射”将原始LUN呈现给VM。去做这个：

• 将LUN呈现给ESXi主机（或主机组，如果要使用群集/ HA）
• 将磁盘添加到您的VM，选择Raw Device Mapping，指向LUN
• 重新扫描VM内的SCSI总线
• 像普通磁盘一样，将fdisk挂载并添加到fstab中。

好处：快速设置，快速使用，容易，如果您发现自己需要V2P，可以将磁盘代表物理主机

缺点：您可能会丢失一些基于VMware的快照/回滚选项，具体取决于您使用物理还是虚拟兼容模式

另一种选择是在LUN上创建VMFS以创建数据存储，然后将VMDK磁盘添加到该数据存储上的VM。

• 好处：如果您购买了使用许可，它将对Storage vMotion友好。这允许在LUN甚至SAN之间进行VMDK磁盘的热迁移。

在这两种情况下，如果VMware或您的VM在故障期间吞噬文件系统，则您处于类似的风险境地；尽管可以使用哪些恢复选项会大不相同，但一个并没有比另一个明显好。

除非必须，否则我不会部署RDM。我发现他们不能像VMDK那样给我带来很大的灵活性（而且我被一些使它们在执行其他存储操作时不切实际的错误所困扰（由于已修复，请参阅该链接中的RDM部分））

对于您的VM，最好的灵活性选择是将文件服务器的启动磁盘作为VMDK存储在SAN上，以便在主机发生故障时让其他主机对其进行启动。使用VMware的HA功能，将自动在另一台主机上启动VM（VM将在第二台主机上启动，就好像电源已经关闭；期望像普通服务器一样执行通常的fsck和魔术来启动它）。注意，HA是一项许可功能。

为了减轻VM故障，您可以构建文件服务器的轻型克隆，其中包含引导和使SAMBA以已配置状态启动并将其存储在每个主机的本地磁盘上所需的最低限度的最低限度，以等待从中添加数据驱动器。失败的虚拟机并打开它。

如果SAN发生故障，这可能会或可能不会为您提供额外的选择。在最佳情况下，您的数据存储将需要fsck或其他修复，但是至少您不必在顶部修复，重建或配置VM。最坏的情况是，您丢失了数据，需要回到磁带上……但是无论如何，您已经处于这种状态。

我坚持使用vmdk图像，以防万一您将来使用vmotion时，您永远不知道会有预算。

如果您的计算机不是群集的，那么就我而言，管理它们的最佳方法是尝试尽可能平均地分散负载。我有3个非群集的2950，其中来自最关键的VM的负载在每个负载上尽可能多地为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 LUNS的vmdk文件中。设置2个VM，并将Heartbeat用于IP和服务的故障转移。心跳将转移服务IP，并可以处理脚本以在适当的情况下卸载/装载数据LUN。您甚至可以编写一些VMware Remote CLI脚本来确保关闭的VM断电以进行防护。通过心跳直接协调系统之间的风险，访问数据交换/运行相同服务的风险应该非常低。此处的关键是确保数据LUN的安装/卸载和服务的启动/关闭是由Heartbeat而非常规的初始化机制处理的。

可以通过监视系统来完成备用故障转移。当它检测到关闭的主机时，可以使用VMware Remote CLI发出电源关闭（为安全起见），然后打开备份虚拟机的电源。在这种情况下，故障回复是相当手动的。

在我的“小”环境中，我还没有看到VMDK损坏。我还意识到，如果您拥有2台以上ESX（i）主机或12台VM，您将希望获得vCenter来跟踪所有内容。考虑到这些好处，某些Essential / Plus软件包的成本不太高。

马特，您知道我不使用VMware，但我一直在Xen中使用“ RAW”。仅有少量的VM轻载，我怀疑您会看到很多性能差异。但是，当您开始接触越来越多的来宾时，如果所有来宾都位于同一文件系统上，那么您将最终遇到队列深度问题。对于NFS支持的存储尤其如此。NFS服务器并没有什么问题，但是大多数NFS客户端实现都很糟糕。

如果您正在寻找冗余（san失败），我不知道一种同步vmdks的好方法。但是，如果您使用块设备，您仍然可以使用DRBD来仅复制您想要/需要复制的虚拟机。

我认为您应该问自己“我是否打算回过物理服务器”

如果答案可能是，那么也许您应该坚持使用RDM。带有RDM的ESXi（我认为）需要您购买一些设备才能使光纤正常工作（同样，不能在esxi上100％保证）。

我们有一台机器，我刚刚使用RDM将其从物理服务器快速迁移到ESX（4.0）。我混合使用Linux和Windows机器（这两个平台都超级简单）。由于旧的FBSD内核不支持RDM，因此我们在不能使用RDM的物理服务器上仍然有一些运行良好的FreeBSD（6.0及更早版本）。速度很快，除了指向LUN然后安装VMWare工具外，我无须做其他任何事情。脑死了容易..没有转换器没有大惊小怪...

您应该问自己的另一件事是“我想使用VMWare的哪些功能？”

根据您的回答，除了VMDK，您可能别无选择。如果您将SAN用于快照，并且不关心例如使用vmware。

到现在为止，我会与您分享一些注意事项。Vmotion在RDM和VMDK上同样出色，另一方面，Storage Vmotion仅在非RDM上正常工作，并且试图使用Vmotion从RDM迁移到VMDK很烂只需使用转换器即可。大多数Linux发行版都有一个开源vmware工具包，这使得安装工具成为一个问题。备份设备确实运行良好，并且没有vmware，但没有执行我们想要的工作。我强烈建议从vmware上课。我花了一周时间，值得每分钱的VMWare支持很棒。.如果您获得支持合同并且必须打电话给他们，那是最重要的..我很沮丧地找到可以帮助我的人（很多菜单。 ），但一旦我获得它们，它们始终会提供快速可靠的支持。