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