如果您负担不起或不需要在发生故障时等待上线的集群或备用服务器，那么您似乎可以将一台功能强大的服务器提供的服务拆分到两台功能较弱的服务器上。因此，如果服务器 A 宕机，客户可能无法访问（例如电子邮件），如果服务器 B 宕机，他们可能无法访问 ERP 系统。
虽然起初这似乎更可靠，但它不只是增加了硬件故障的机会吗？因此，任何一次失败都不会对生产力产生如此大的影响，但现在你要为自己设置两倍的失败。
当我说“不那么结实”时，我真正的意思是较低的组件规格，而不是较低的质量。因此，一台机器规格用于可视化，而两台服务器规格分别用于减少负载。
通常建议使用 SAN，以便您可以使用集群或迁移来保持服务正常运行。但是 SAN 本身呢？如果我要把钱花在将发生故障的地方，它不会放在基本的服务器硬件上，而是与存储有关。如果您没有某种冗余 SAN，那么那些冗余服务器不会给我很大的信心。就我个人而言，对于小型操作而言，投资具有冗余组件和本地驱动器的服务器会更有意义。我可以看到大型运营的好处，因为 SAN 的价格和灵活性具有成本效益。但是对于较小的商店，我没有看到这个论点，至少不是为了容错。
这一切都归结为风险管理。对您的 IT 系统进行适当的成本/风险分析将帮助您确定将钱花在哪里以及您可以或必须承受的风险。一切都有成本……这包括高可用性和停机时间。
我在一个小地方工作，所以我理解这种斗争，我的 IT 极客不希望任何地方出现单点故障，但在每个级别上这样做的成本并不是一个现实的选择。但这里有几件事我可以在没有巨额预算的情况下完成。但这并不总是意味着消除单点故障。
网络边缘：我们有 2 个互联网连接，一个 T1 和 Comcast Business。计划将我们的防火墙转移到一对使用 CARP for HA 运行 pfSense 的旧计算机上。
网络：为网络核心获取几个托管交换机，并使用绑定在两个交换机之间拆分关键服务器，以防止交换机故障导致整个数据机柜失效。
服务器：所有服务器都有 RAID 和冗余电源。
备份服务器：我有一个较旧的系统，它不如主文件服务器强大，但它在 raid5 中有几个大型 sata 驱动器，每小时对主文件服务器进行快照。我为此设置了脚本，以便在它出现故障时将角色切换为主要文件服务器。
异地备份服务器：与现场备份类似，我们每晚通过 VPN 隧道将服务器备份到其中一个业主的房子。
虚拟机：我有一对物理服务器，它们使用 Xen 在虚拟机内部运行许多服务。这些在主文件服务器上运行 NFS 共享，如果需要，我可以在物理服务器之间进行实时迁移。
我认为这是一个有很多答案的问题，但我同意在许多较小的商店中，多个服务器解决方案可以工作，正如您所说，如果出现故障，至少有些事情会继续进行。但这取决于失败的原因。
很难涵盖所有基础，但冗余电源、优质电源和良好的备份可以提供帮助。
我们已将 Backup Exec System Recovery 用于一些关键系统。与其说是日常备份，不如说是一种恢复工具。如果可用，我们可以恢复到不同的硬件，并且我们还使用该软件将备份映像转换为虚拟机。如果服务器出现故障，我们需要等待硬件修复，我们可以在不同的服务器或工作站上启动 VM，然后继续前进。并不完美，但它可以快速启动并运行。
关于 SAN：几乎您使用的任何东西都是多余的。即使是单个机箱，内部也会有双电源、双连接器和双“磁头”，每个磁头都与所有磁盘相连。即使是像戴尔出售的 MD3000 这样简单的东西也具有所有这些功能。SAN 被设计为您的机器的核心，因此它们可以承受几乎任何随机硬件故障。
话虽如此，你有一点，冗余并不总是最好的选择。特别是如果它增加了复杂性。（它会）一个更好的问题是......“公司将接受多少停机时间”。如果您的邮件服务器丢失一两天并不是什么大问题，那么您可能不应该为其中两个而烦恼。但是，如果网络服务器中断每分钟都开始让您损失真金白银，那么也许您应该花时间为它建立一个合适的集群。
服务器越多，发生故障的机会就越大，这是看待它的一种方式。另一种情况是，如果一个人坏了，你就会 100% 的吱吱作响，就像你说的那样。
最常见的硬件故障是 HD，就像您在上面所说的那样。无论您想在多少之间拆分操作，都需要对存储进行 RAID。
我会投票给几台服务器（当然是 RAID 的）而不是一台大型服务器，这既是为了操作稳定性，也是为了性能。更少的软件碰撞到每个请求资源，减少混乱，更多的磁盘被读取/写入，等等。
我个人会选择多台服务器。我认为在这种情况下设备故障的可能性不大。是的，您有更多可能发生故障的设备，但是任何给定单元发生故障的几率应该是恒定的。
在非冗余/非 HA 配置中拥有多台服务器使我能够在发生故障时将部分工作卸载到另一台服务器。所以，假设我的打印服务器出现故障。如果我可以在修复打印服务器的同时将几台打印机映射到文件服务器，那么对操作的影响就会减少。这才是真正重要的地方。我们经常倾向于谈论硬件冗余，但硬件只是维持运营连续性的工具。
我在一家小商店（一个人 IT 部门）工作，在任何情况下都不会将我的多台服务器换成一台。如果任何一台服务器出现故障，我可以选择将现在缺少的服务添加到另一台机器，或者甚至只是将它们设置在备用 PC 上。对于大多数事情，我们可以忍受一两个小时的中断，但我们不能忍受所有系统的完全中断。虽然我可以用 PC 替换我们的任何服务器，至少是暂时的，但我没有，或者可以很容易地掌握任何强大到足以同时替换所有服务器的东西。
您最初的帖子假设您买不起集群，但您考虑使用两台服务器（不包括备份）的解决方案。这意味着您很可能手头有三台服务器，足以启动一个集群。
有一些中间解决方案可以避免 SPoF，并且仍然适用于中小型企业：没有 SAN 存储的节点到节点复制。
例如，Proxmox 支持这一点（但我认为 XCP-ng/XenServer 也可能支持 ESXi）。
让我们考虑一个 3 个节点的设置。全部带有 RAID、冗余 PSU、冗余网络。
然后有两个选择：
这种设置可以容忍网络故障、总节点故障和主要节点故障（三者中的任何一个），停机时间约为 1 分钟（大约是虚拟机启动所需的时间）。缺点是自上次复制以来数据丢失（取决于您的设置和硬件性能，可能低至 1 分钟，高至几个小时）。
使用第二个选项（VM 通常在节点 A 和 B 之间拆分），您必须优先考虑允许哪些 VM 重新联机。因为，由于您的 VM 负载通常在两台服务器之间分配，因此将它们全部运行在单个节点上可能会耗尽节点的 RAM 或拥塞 CPU。
“虽然一开始这看起来会更可靠，但这不只是增加了硬件故障的机会吗？”
从来没有这么简单，强大的大型服务器可能做得更好或更糟。他们可能有更高质量的零件，但可能会产生更多热量并且没有适当冷却。一个强大的服务器有更多的内存，更多的 CPU 等等，所以最后可能你在这两种情况下都有同样多的 CPU，所以服务器可能不是要考虑的正确单元。
由于机会的复杂性，我认为任何最具成本效益的都会获胜。如果您必须为许可证付费，则 1 台大型服务器可能比几台小型服务器便宜，具体取决于许可结构。
我的默认方法是避免使用任何集中式基础设施。例如，这意味着没有 SAN，没有 Load Balancer。您也可以将这种集中式方法称为“整体式”。
作为一名软件架构师，我正在处理客户的基础架构。这可能意味着使用他们自己的私有数据中心，或者使用 AWS 之类的东西。所以我通常无法控制他们是否使用 SAN。但是我的软件通常跨越多个客户，所以我构建它时就好像它会在网络上隔离的单个机器上运行一样。
电子邮件示例
电子邮件很奇怪，因为它是一个遗留系统（有效）。如果今天发明了电子邮件，它可能会在 Web 服务器上使用 RESTFul API，并且数据将存储在可以使用普通工具（事务复制、增量备份）复制的数据库中。
软件架构解决方案是，Web 应用程序将连接到可用节点列表中的一个（随机），如果不可用，它将尝试连接到另一个节点（随机）。如果服务器太忙，客户端可能会被踢出服务器。在这里，不需要负载均衡器连接到网络农场；而且，无需 SAN 即可实现高可用性。也可以按部门或地理位置对数据库进行分片。
商品意味着...
因此，您可以使用几台商品化的低功耗低成本机器，而不是使用昂贵的 1 或 2 台服务器和具有内部冗余措施的 SAN。
简单- 冗余纯粹来自设备的数量。您可以通过机器数量轻松验证冗余。你更正确地估计他们有更高的失败机会并为此做好准备。
冗余百分比- 如果您有 2 台服务器，如果其中一台出现故障，则剩下 1 台 (50%)。如果您有 10 台商品服务器，其中一台出现故障，则剩下 9 台 (90%)
库存- 可以从附近的任何商店以优惠的价格轻松获得商品设备。
兼容性- 与光纤通道、磁盘卷格式、商品设备和软件架构的各种标准相结合，意味着您不会局限于单一的设备型号或品牌。
性能- SAN 上有 2 台设备，它们需要在同一个房间内。使用商品机方法，如果你有 5 个办公室，每个办公室可以有 2 个，办公室之间有 VPN WAN 冗余。这意味着软件和通信在 LAN 上的访问时间小于 1 毫秒。
安全性——建立在高度冗余的基础上，您可以轻松地将节点重建为商品常规流程。想要重建一个单一的 2 台服务器集群？拿出说明书。通过经常（通过自动化）重建机器，您可以使软件保持最新，并防止任何黑客或病毒在您的网络上站稳脚跟。
注意：您仍然需要有多个交换机和网关路由器冗余