spa*_*spa 9 virtualization high-availability
对于一个项目，我的任务是为网上商店和 CMS 系统规划高可用性设置。但是，当然，该项目的预算很紧。因此，高端解决方案可能不在预算之内。
将有两台机器运行 Web 服务器（CMS、商店），一台运行数据库的机器，以及一台运行传真服务器的机器，用于向合作伙伴交付订单。所有系统都运行 Linux。所有这些组件都需要高度可用，并且应该支持透明的故障转移。
为了降低硬件成本，我想到了虚拟化环境。那里有很多信息，但我不知道确切地开始。很明显，至少需要服务器作为虚拟机的主机，因此不存在单点故障。
支持高可用性的最佳方式是什么？
第一个问题是在这种情况下哪种虚拟化解决方案是最好的。需要有某种管理界面。需要有一种方法将正在运行的虚拟机从一台主机移动到另一台主机，以便维护主机。需要某种机制，以便在一台主机出现故障时虚拟机仍然可用。你能在这里就一个有效的解决方案提出建议吗？
在大多数情况下，共享文件存储似乎是高可用性的先决条件（期望相当昂贵的 VMware vSphere）。但是，宁可在虚拟机主机上投入更多资金，也不愿向设置中添加另外两台服务器以提供冗余 NFS 文件存储。有没有可能只和两个虚拟机主机相处？一个解决方案可能是两个也将这两个用作 NFS 主机。这样做有很大的性能损失吗？
编辑：我的目标是 99.9% 的可用性。但是，不需要 24/7 可用，因为有正常的营业时间，这提供了一些操作空间。必须以某种方式保证可用性的时间段是上午 10 点到午夜之间。
Mar*_*son 13
作为一般概述，要实现高可用性，您需要：
数字 1 听起来很简单 - 购买两台相同的服务器。
第二个可以通过复制 SAN（昂贵、非常快、非常可靠）或每个服务器上的复制文件系统（便宜、速度和可靠性取决于您对所选技术的了解）来实现。
第 3 名可以通过 SAN（一个存储 LUN，由两台服务器访问）或复制文件系统（两个单独的存储区域，每个服务器只能看到自己的）来实现。
第 4 项可以通过心跳应用程序实现。
为了以较小的预算做到这一点，比如说 VMWare vSphere，您可以使用 SAN或VMWare 现在提供一个自我复制的存储设备，它在两台服务器上提供两个不同的数据存储，可用于高可用性。vSphere 还提供内置检测信号和高可用性配置。
要在没有预算的情况下做到这一点，您可以沿着 Xen 路径前进，并使用 DRBD 在两个节点之间复制存储。然后，您设置心跳以切换活动的 DRBD 存储节点和 Xen 实例，以便在第一台主机出现故障时启动第二台主机上的 VM。
使用这些基本建议，您不会获得5-9 (99.999%) 的正常运行时间，但如果您知道自己在做什么，则可以使用最便宜的方法轻松获得3-9 (99.9%)。
在讨论共享存储时，您从“购买这笔现金需要多少现金”来谈论“费用”。当然，这是一个完全正确的观点，到处都是钱。
但是如果您在谈论高可用性，那么您还需要问“我们为什么需要高可用性？” 如果答案是，例如，“因为该企业的在线销售额每小时超过 2000 美元，所以如果我们休息一个小时，那么我们就损失了 2000 美元”，那么费用和负担能力的问题就变成了“我们可以吗？负担得起不购买支持或大大改善我们的高可用性部署的东西吗？”
这是一个重要的细节，它会影响您对预算的评论——IT“尾巴”不能通过坚持对一个小问题采取过于复杂和昂贵的解决方案来摇摆业务“狗”，但同时如果业务有其 IT 基础设施的某些要求，那么它必须准备好为它们正确预算或调整其要求。
我认为虚拟化在提高系统可用性方面有很大潜力，但它不是魔杖。硬件方面虽然很重要，但对于软件要求来说是次要的——如果前端应用程序进行对话，那么在其中一个 SQL 服务器崩溃的情况下，SQL 数据库集群没有任何问题。数据库阻塞，因为它无法处理故障转移。
并且在数据中心中并排放置的两台“高度可用”服务器仍然容易受到电源故障、盗窃等的影响。同样，根据对“我们为什么要这样做？”的回答，您可能需要充分考虑这一方面小心，因为它会增加项目的很多部分的费用和复杂性。
在不知道您使用哪个数据库和应用程序服务器的情况下，我建议：
HA-示例：
如果您在应用层上执行 HA，该层最了解如何复制会话。如果一个节点出现故障（计划内或计划外），幸存的节点将接管——包括会话。