比方说，我有一个给定的域的2个IP（循环赛DNS）。 如果一个IP变得没有响应，客户端是否会尝试连接到另一个IP？ 或者他们只是不能build立与域的沟通？
对于一个项目，我有一个计划网店和CMS系统的高可用性设置的任务。 不过，这个项目当然是预算紧张的。 所以高端解决scheme可能不在预算之内。 将有两台运行Web服务器（CMS，商店）的机器，一台运行数据库的机器以及一台运行传真服务器的机器，以便将订单交付给合作伙伴。 所有系统都运行Linux。 所有这些组件都需要高度可用，并且应该支持透明故障转移。 为了降低硬件成本，我考虑了虚拟化环境。 那里有很多的信息，但我不知道要开始。 似乎很明显，至less需要服务器作为虚拟机的主机，这样就没有单点故障。 哪种方法可以支持高可用性？ 第一个问题是哪种虚拟化解决scheme在这种情况下是最好的。 需要有某种pipe理界面。 需要有一种方法可以将正在运行的虚拟机从一台主机移动到另一台主机，因此可以完成对主机的维护。 需要有某种机制，如果一台主机发生故障，虚拟机仍然可用。 你能在这里提供一个有效的解决scheme吗？ 在大多数情况下，共享文件存储似乎是高可用性的先决条件（预计VMware vSphere相当昂贵）。 但是，宁愿投入更多的钱在虚拟机主机上，而不是增加另外两台服务器到设置提供一个冗余的NFS文件存储。 是否有可能只与两台虚拟机主机相处？ 一个解决scheme可能是两个使用这两个NFS主机也。 这样做会有很大的性能损失吗？ 编辑：我的目标是99.9％的可用性。 然而，由于有正常营业时间，所以不需要24/7可用性，这给了一些回旋空间。 在某种程度上保证的可用时间是在上午10点到午夜之间。
我们有一个我们用于处理函数的GlusterFS集群。 我们希望将Windows集成到其中，但在如何避免服务于GlusterFS卷的Samba服务器的单点故障方面遇到一些麻烦。 我们的文件stream如下所示： 文件被Linux处理节点读取。 文件被处理。 结果（可以很小，可能很大）在完成后写回到GlusterFS卷。 结果可以写入数据库，也可以包含多个不同大小的文件。 处理节点从队列中取出另一个作业并转到GOTO 1。 Gluster很棒，因为它提供了一个分布式卷，以及即时复制。 抗灾能力很好！ 我们喜欢它。 但是，由于Windows没有本地的GlusterFS客户端，我们需要一些方法让我们的基于Windows的处理节点以类似的弹性方式与文件存储进行交互。 GlusterFS文档指出 ，提供Windows访问的方法是在已安装的GlusterFS卷上build立一个Samba服务器。 这将导致像这样的文件stream： 这对我来说看起来像是一个单一的失败点。 一种select是对Samba进行集群 ，但是现在似乎是基于不稳定的代码，因此无法运行。 所以我正在寻找另一种方法。 关于我们抛出的各种数据的一些关键细节： 原始文件大小可以从几KB到几十GB之间的任何地方。 处理过的文件大小可以从几个KB到一个GB或两个。 某些进程（如挖掘存档文件，如.zip或.tar）可能导致大量的进一步写入，因为所包含的文件将被导入到文件存储中。 文件计数可以达到数以百万计。 此工作负载不适用于“静态工作单元大小”Hadoop设置。 同样，我们评估了S3风格的对象存储，但发现它们缺乏。 我们的应用程序是用Ruby编写的，我们在Windows节点上有一个Cygwin环境。 这可以帮助我们。 我正在考虑的一个选项是在安装了GlusterFS卷的服务器集群上的简单HTTP服务。 由于我们所做的Gluster基本上是GET / PUT操作，这似乎很容易转移到基于HTTP的文件传输方法。 把它们放在一个负载平衡器对后面，Windows节点可以把HTTP PUT放到他们小心脏的内容上。 我不知道的是GlusterFS一致性如何维持 。 HTTP代理层在处理节点报告完成写操作和在GlusterFS卷上实际显示时间之间引入了足够的延迟时间，我担心后来处理尝试拾取文件的处理阶段不会find它。 我很确定，使用direct-io-mode=enable mount-option会有所帮助， 但是我不确定这是否足够 。 我还应该做些什么来提高连贯性？ 或者我应该完全追求另一种方法？ 正如Tom指出的那样，NFS是另一种select。 所以我跑了一个testing。 由于上述文件具有我们需要保留的客户端提供的名称，并且可以使用任何语言，因此我们需要保留文件名。 所以我用这些文件build立了一个目录： 当我从安装了NFS客户端的Server 2008 R2系统上安装它时，我得到如下所示的目录： 很显然，Unicode并没有被保留下来。 所以NFS不会为我工作。
我有几种情况需要在发生故障（服务器挂起或崩溃）时将应用程序从一台服务器迁移到另一台服务器。 在solaris上，我们使用VCS（Veritas Cluster Server）执行此操作。 什么选项可用于Linux？ 请说明为每个设置/维护或成本（如果有的话）的努力水平。 – 更多细节添加 – 给出复杂程度的一个想法： 失败的服务器可能会挂起或崩溃，恕不另行通知，可能仍然是“可以ping通” 恢复服务器需要启动故障转移的应用程序 一旦服务器启动/关机失败，由于不与恢复服务器进行干预而变成被动服务器。 这是一个数据收集或计算节点，而不是数据库，所以更简单的解决scheme可以工作。 – 更多细节（对不起） – 共享存储不是一个选项，但是没有太多的状态（如果有的话）需要从一台服务器迁移到另一台服务器。 我们通过rsync保持两台服务器同步。 到目前为止，非常感谢你的所有post。
大多数浏览器如果从DNS服务器获取多个Alogging，其行为如何？ 只要可以访问，就坚持一个IP（如果IPclosures，只能使用另一个IP）？ 或者他们无时无刻都在切换？ 如果大多数当前的浏览器都支持一个IP，那么DNS-RR就足够了，作为一个简单的故障转移解决scheme。
我有一个需要访问NFS存储的CentOS 6.3客户端。 有两台NFS服务器提供与集群文件系统一起存储在SAN上的相同内容。 如果需要，我如何设置CentOS故障切换到备份NFS服务器？ 当我Google的时候，我一直在阅读，Linux不支持这个，但是这会很奇怪，因为有很多关于如何设置集群Linux NFS服务器的信息。
我即将将单服务器单数据库Web应用程序转换为具有两个物理位置（现在）的服务器的物理分布式高可用configuration。 现在，显然，我需要一个负载均衡器（在这种情况下更像是一个反向代理，但为简单起见，我将其称为“负载均衡器”），这会将mywebsite请求路由到node1.mywebsite或node2.mywebsite 。 但是，如果我的负载均衡器出现故障，我认为高可用性服务器是无用的。 所以，我的思路，我实际上需要两个负载平衡器，每个位置一个。 但是，我仍然需要一个外部访问点，因此我需要一个负载平衡器来负载平衡器，而这个负载平衡器又需要在各个位置之间进行平衡……这一直在继续。 那么我的推理有什么问题呢？ 在实践中，如何确保我的负载均衡器的高可用性，假设每个物理位置都可能长时间断开电源？ PS ：我知道我对HA和负载均衡之间的区别的理解最好是平庸的。 我想要的是一个可用的服务器，即使在一个位置的电源closures。 谢谢你的理解。
我在centos 5运行带有ocfs2 ，并计划使用packemaker 。 过了一段时间，我正面临着drbd裂脑的问题。 version: 8.3.13 (api:88/proto:86-96) GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by [email protected], 2012-05-07 11:56:36 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown r—– ns:0 nr:0 dw:112281991 dr:797551 al:99 bm:6401 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:60 我无法将我的drbd切换到辅助。 drbdadm secondary r0 1: State change failed: (-12) Device is held open by someone Command 'drbdsetup 1 secondary' terminated with exit […]
在一个早上不会出现的服务器有点恐慌之后，高层决定业务需要高可用性/故障切换设置。 我们有5个主要服务器（4个Linux，1个OpenBSD），所有这些服务器都需要运行以供公司操作。 三个服务器是相当标准的（文件/networking/数据库），第四个处理大多数networking路由和networking代理，而第五个支持我们的电话系统，并具有非标准的硬件。 我的老板曾经说过，服务器故障的周转时间应该在30分钟以内。 我在这个领域的经验是不存在的（我只是一个“提升”的程序员），所以我想我的问题可以归结为： 这是什么，甚至应该尝试一个具有平均服务器pipe理技能的人。 如果是这样，我应该读什么，我该和谁谈话？ 谢谢。
我拥有并运营visualwebsiteoptimizer.com /。 该应用程序提供了一个代码片段，我的客户在他们的网站中插入了一些特定的指标。 由于代码段是外部JavaScript（位于站点代码的顶部），因此在显示客户网站之前，访问者的浏览器会联系我们的应用服务器。 如果我们的应用程序服务器出现故障，浏览器会在超时（通常是60秒）之前继续尝试build立连接。 正如你所想象的，我们不能在任何情况下让我们的应用程序服务器停机，因为这不仅会影响我们的网站访问者的体验，也会影响我们客户的网站访问者的体验！ 目前我们正在使用DNS故障转移机制，其中一台备份服务器位于不同的数据中心（实际上是不同的大陆）。 也就是说，我们从3个不同的位置监控我们的应用服务器，一旦检测到服务器closures，我们将Alogging更改为指向备份服务器IP。 这对大多数浏览器来说工作正常（因为我们的TTL是2分钟），但IEcaching了30分钟的DNS，这可能是一个交易杀手。 看到我们最近的一篇文章visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/ 那么，如果应用程序数据中心遭受重大中断，我们可以使用什么样的设置来确保几乎即时的故障切换？ 我在这里读www.tenereillo.com/GSLBPageOfShame.htm有多个Alogging是一个解决scheme，但我们不能承担会议同步（还）。 我们正在研究的另一个策略是有两个Alogging，一个指向应用程序服务器，另一个指向反向代理（位于不同的数据中心），如果启动则parsing为主应用程序服务器，如果启动则备份服务器。 你认为这个策略是否合理？ 为了确定我们的优先事项，我们可以保留自己的网站或应用程序，但我们不能让客户的网站因为停机而放慢速度。 所以，如果我们的应用程序服务器closures，我们不打算回应默认的应用程序响应。 即使是一个空白的响应就足够了，我们只需要该浏览器完成该HTTP连接（没有别的）。 参考：我读这个线程这是有用的serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure