我正在尝试使用虚拟服务器为 J2EE Web 应用程序托管构建一个体系结构。我没有虚拟化经验。我目前有 1 台安装了 Apache/Jboss/Postgresq/Proftpd 的服务器，我想设计一些服务在不同服务器上运行的东西。
1 个 HTTP 负载平衡器（+ 1 个用于故障转移的 HTTP 服务器）--> 多个应用程序服务器或 Web 服务器--> 数据库服务器（+ 1 个用于复制的服务器）
文件将存储在 SAN 和 2 个服务器上，用于数据库和 HTTP 负载均衡器（非虚拟）
这是我的想法：建筑
- 您如何看待这种架构？
- Jboss 在 Xen（或 VMWare）虚拟机上运行良好吗？
- 心跳是获得故障转移的最佳工具吗？
- 我将数据库放在专用服务器上（而不是 SAN 上）是否正确？
- 我的 SAN 将用于静态文件（图像...）。我应该使用 iSCSI 还是光纤通道？
谢谢你 ！！！
一般来说，如果您预期高负载，我会 100% 将您的数据库放在 FC SAN 上，我们在 VMWare ESX 3.5U4 内的 Oracle 重新标记的 RHEL 5U3 上运行 JBoss，效果很好，如果您可以使用 VMWare 的 HA 进行故障转移你希望吗？
我的2c
减去 FTP，该图看起来非常像我们的系统之一，它对我们来说运行良好。至于你的其他一些观点：
我们有一些运行 JBoss 的 RH4 虚拟机 (ESX 3.5)，它们都很好。在构建虚拟盒子时，请牢记 JBoss 的内存要求。
如果您负担得起，如果您期望高吞吐量或未来扩展，我肯定会选择基于 FC 的 SAN。
根据我的经验，具有良好磁盘子系统的物理数据库服务器与访问 SAN 的虚拟数据库服务器之间没有太大的性能差异。
Xen 虚拟化非常稳定且配置良好，可以为您提供非常好的性能（可以肯定，这不是一项微不足道的任务！）。几乎唯一受到严重影响的应用程序是高带宽应用程序，例如文件服务器或 DBMS。因此，如果您预计负载很重，将数据库放在真实服务器上是明智之举。其他一切都将受到您的互联网带宽的限制，因此虚拟化它们不是问题。
关于 SAN：如果您有良好的交换机，通常将 iSCSI 用于 Xen 存储就足够了（很难学习！3Com 不太好，最好选择 HP 或 Dell）。如果数据库不会增长到 TeraByte 范围，我会使用内部存储（如果需要，RAID1 上的 10K 或 15Krpm SAS 磁盘）而不是 SAN。如果数据库超出此范围，最好投资于一个好的 FC SAN（我帮不了你）
如果您的负载均衡器暴露在不受信任的网络中，我会考虑为不同区域的应用程序服务器和数据库服务器设置防火墙。您的服务器角色已经很好地分层了。另外，我会尽量避免直接访问我的 FTP 场的数据库服务器。
将 DBMS 放在物理硬件上总是更安全的选择。不要虚拟化，除非你的背靠墙并且你的老板比你大。
有钱就买FC。单个 iSCSI 适配器比单个 FC HBA 慢 4 倍。您可以通过添加千兆以太网适配器获得 FC 的理论带宽，但您不会获得低延迟。
您是否考虑过将您的 VM（虚拟机）放在 SAN 上？对于虚拟机而言，FC 的低延迟非常重要，因为 VM 会生成许多小型 I/O。对于 VM 的更便宜的 NAS 选项，我更喜欢 NFS 而不是 iSCSI。备份 VM 只是一个文件夹副本，配置更容易。