标签: redundancy

大型企业中哪个更标准：RAID5 或 RAID10？

一台电源插110V，另一台电源插208V，可以运行双电源服务器吗？我们询问了供应商，他们说他们从未测试过它或其他一些“我不知道”类型的答案。电源都在 110 和 208 下正常工作，没有任何问题，这是有问题的“混合”操作。

如果您在两台服务器上提供服务以确保高可用性，那么以完全相同的方式配置它们会更好，还是应该引入细微的差异以防止“异常配置”错误？

我们在 Linux (Ubuntu LTS)、Nginx、Apache 和 Python WSGI 堆栈上托管了一个基于 Django 的网站，在负载均衡器后面的三台服务器上复制。目前它们托管在亚马逊云中，但我们将来可能会转移到我们自己的数据中心。我们最近在所有三台服务器上都遇到了一个问题，只能通过升级内核来解决，这让我们认为这个特定版本的内核与亚马逊当时可能已经开始使用的物理硬件不兼容。

这让我想到：让所有机器保持完全相同的配置会更好（更容易管理？），还是应该保持稍微不同的东西，这样两个组件之间的不兼容只会在一台机器上而不是所有机器上表现出来其中，保持您的网站在空中？

我有兴趣在 Amazon EC2 上构建两个具有故障转移功能的容错/冗余 NFS 服务器。我熟悉 DRBD、Heartbeat 等工具/技术。亚马逊是否提供了通过他们的平台实现这一目标的任何特定方式？

一个合适的例子可能是文件保存在一个单独的、冗余的 EBS 上——如果发生故障，一个新实例会自动从预先构建的 AMI 启动，安装 EBS 卷，并无缝转换 IP 地址。

这可能吗？有比亚马逊更好的平台吗？你能给我一个关于我们正在谈论的底层架构的广泛概念吗？

我在该国每个站点的不同数据中心有 2 个 CentOS linux 服务器。这些 linux 机器在带有 MySQL 后端的 Apache 上运行一个小型网站。目前，它们之间没有 VPN 连接，它们进行通信的唯一方式是通过公共 IP 空间。

我的问题是，如果其中一个失败，另一个将接管（主/从关系），那么最好的方法是什么让它们变得多余？我希望能够使用我目前拥有的两台服务器来做到这一点，而无需添加第三台。我猜我需要在两者之间创建一个 VPN，然后使用类似 DRDB for MySQL 的东西。

你会推荐什么？

我正在构建一个网络应用程序，其中正常运行时间是关键。我知道 100% 正常运行时间是不现实的，但我想达到 5 个 9。我不确定实现这一目标的最谨慎方法。

我的初步计划是让 Web 应用程序在两个地理上独立的数据中心运行。“主”数据中心将包含主服务器，这将复制到其他地方未使用的“从”服务器。如果主数据中心发生停机，DNS 故障转移会将流量转移到“从”服务器。这种技术存在一些挑战，包括由于奇怪的 DNS 记录缓存等原因，一些用户在一段时间内无法访问该站点。

但是，我已经阅读了很多意见，指出 DNS 故障转移不是一个好的解决方案，您应该将所有内容都保存在一个数据中心并专注于那里的冗余。我看到的问题是，即使是好的数据中心似乎也有奇怪的网络问题，可能会导致足够的停机时间来打破五个 9 的预期。

我应该使用 DNS 故障转移选项吗？有更好的选择吗？

如果第 1 个 UPS 出现故障，如何设置 UPS 以提供冗余电源，则系统应在第 2 个 UPS 上工作，如果第 2 个 UPS 出现故障，则系统应与第 1 个 UPS 一起工作，如服务器电源。

从最初的阅读来看，微软即将推出的“存储空间”似乎是一个类似 LVM 的 Windows 工具。

这是一个正确的评估吗？

如果它不仅仅是LVM-for-Windows，那么它是什么，以及如何在 Linux/Unix 上复制这种方法？

假设我有一台刀片服务器 HP C7000，带有三个刀片。

一季度。是否有任何灾难恢复技术可以在刀片之间提供冗余？如果任何一个刀片出现故障，第二个刀片应该具有相同的配置。

Q2。是否可以在刀片之间启用内存和存储共享？如果我观察到刀片上的使用率更高，并且我想使用第二张卡的内存来扩展第一个刀片的资源。

Q3。虚拟化中的冗余 - 哪些应用程序和技术可以用于冗余？

我正在开发一个客户端-服务器系统，其中所有客户端目前都将他们的交易提交到基本上一个单一的西海岸 IP 地址，以到达所谓的“网关”应用程序。网关进行一些记帐并将每个事务分派到多个数据库服务器中的任何一个进行最终处理。服务器将结果直接返回给客户端（而不是通过网关返回）。

计划是在东海岸添加第二个网关，用于冗余和故障转移。它通常仅处于备用状态，旨在在工作网关出现故障时接管并成为实际网关，本质上是此处所示的经典配置。

一些参与者认为只有一个备用网关是不够的，我们还应该实施第二个备用网关，比如在中西部。其他人则争辩说，两个备用站的额外成本、复杂性和管理是不必要的，并且两个海岸上网关同时不可用的可能性大到不必担心。

什么被认为是最佳实践？多少冗余（就客户端可用的物理独立接入点而言）通常被认为是名义上的？双重故障是否足够普遍，以至于经常会后悔只有一个备用？

编辑：关于“计算”成本与我需要或想要的冗余量的收益，我想最好将我的问题改写为：

指示地理上不同的 IP 地址集合同时无法访问的频率的统计数据在哪里？

换句话说，像这样的表

On average, 1 west coast IP + 1 east cost IP
are simultaneously unreachable 1 day/year.
On average, 1 west IP + 1 east IP + 1 southern IP
are simultaneously unreachable 1 hr/year.
On average, 1 west IP + 1 east IP + 1 southern IP + 1 northern IP
are simultaneously unreachable 1 minute/year.
etc.

使得选择所需的冗余量变得相当容易，因为有一个实际基础来计算成本与性能。（我猜“同时无法访问”必须意味着“大量随机分散在全国各地的客户端”，因为单个客户端可能无法访问任何服务器，无论有多少服务器，因为她自己的本地网络故障。）

但是，如果没有这样的表，任何冗余与性能计算都只是猜测。那么： 是否有任何现实生活可用性数据的来源可以作为此类计算的基础？ 还是每个人都只是猜测他们需要什么，并在发现他们猜得低时根据需要进行扩展，或者如果他们猜得高就减少？

提供容错产品的公司似乎希望收集和推广此类数据。另一方面，也许数据会显示 99.99% 的容错客户根本不需要太多冗余。例如，如果我可以使用一整年并且我的东部和西部 IP 地址永远无法同时访问，我就不会考虑添加中西部 …