vsphere 4.1的可扩展devise

您错过了很多信息（特别是有关您的下游局域网端口或任何中间SAN交换机），但我们将其分解成大块。

最简单的就是SAN，只要运行你喜欢的9124到你的NetApp的端口，如果你没有中间交换机，并且使用NPIV而不是运行它们，我会试图将它们作为点对点链接运行ISL中继（不知道NetApp是否可以处理ISL）。 因此，您将创build两个SANnetworking，每个主机端口一个，并直接映射它们 – 不需要VSAN /区域等。

局域网的问题有点棘手，不能覆盖你的物理服务器，因为你没有提供networking要求 – 假设你的下行端口是可以处理中继的交换机，那么我为你的ESX盒子做的每一个flexNIC都被分割成两个vNIC，一个为2Gbps，另一个为8Gbsps，两个适配器都为您的主机分配4个vNIC，使用2Gb vNIC创buildpipe理/ vMotion vswitch，并使用两个8Gb vNIC创buildVMstream量vSwitch。 创build两个VCnetworking，一个用于两个management / vmotion vNIC，另一个用于VMstream量vNIC，将您的真实中继端口放入其端口组中，然后您就不在了。

对于LAN和SAN，都使用硬件MAC / WWN，在这种情况下没有必要使用池中的MAC / WWN。 哦，让你的VC做VLAN标记（除非你计划在两个function单独的中继线，在这种情况下，只是让标签去通过ESX爆发）。

对于ESX来说，这样可能会好起来，而且可能从SAN物理层的angular度来说还不错，但是正如我所说的，你没有给物理LAN端口提供任何帮助。

这是一个相当可怕的问题。 让我们开始吧。

1. 你甚至认为“可扩展”是什么意思？ 有各种可扩展性。 您需要明确地说明您要扩展的内容，以及在您的应用程序中增加了可扩展性瓶颈。
2. 没有一种适合所有可扩展devise的东西。 如果我们不知道如何处理集群，我们可以告诉你关于如何扩展你的应用程序。 即使在相同的应用程序中，不同的使用情况也有很大不同的性能要求。 我们无法猜测您需要保持可扩展性。 你必须告诉我们。 如果您不确定要查找的数字，VMware Capacity Planner应该会对您有所帮助。 把它安装在你的物理服务器上，让它煮一个星期，然后再回来给我们。
3. 您甚至可以通过在三个物理系统上运行五个虚拟机（不包括vCenter）来完成此任务？ 虚拟化有许多灾难恢复方面的好处，但是如果你没有更广泛的整合项目，听起来像是在所有的物理主机上进行从SAN引导，都可以节省大量的资金。
4. 您绝对不希望在同一个刀片式服务器机箱中运行群集虚拟机，尤其是当您依靠HA在发生主机故障时保持可用状态 – 机箱在整个环境中引入单点故障。 如果您只有一个刀片式机箱，请不要使用刀片式服务器。 购买1U或2U pizzaboxes。 你会更快乐。
5. 我从来没有见过无法跟上VMware的SAN。 但是，我已经在SAN中看到了很多不能使用的arrays，因为pipe理员没有正确理解他们的应用程序的I / Oconfiguration文件或者如何影响物理磁盘arrays的devise。

如果你头脑发热，而且你听起来像是因为你不知道你应该问的问题，那么你应该引入一个顾问或至less一个VAR来帮助你启动和运行。 没有专业知识进行configuration或pipe理的虚拟化将会对您的组织造成彻底的灾难。