我处于这种情况，我有一些CentOS Linux服务器，它们都有两个NIC接口。 目前，其中一个接口用于内部通信，另一个用于外部（互联网）通信。 这两个网卡都连接到相同的交换机。 我的意图是将这两个任务都移动到第一个NIC并为其分配内部和外部IP。 这样做将释放第二块网卡的所有任务，然后将其连接到第二台（备用）交换机。 第二个NIC应该也接收一个内部和一个外部IP地址。 我的问题是这样的：我应该怎样做第二个网卡上的IP地址？ 当第一个交换机或NIC中断时，是否有办法将NIC1的IP信息自动分配给NIC2？ 还是我可以总是给出相同的IP信息，让交换机工作出最佳路线？ 什么是已经certificate的技术来完成这个？
我在试图弄清下面devise的技术细节时遇到一些麻烦; 特别是在冗余负载均衡器领域。 Web服务器运行Windows Server 2003 R2 64并通过IIS提供.NET应用程序。 数据库服务器在具有SQL Server 2008的SQL Server故障转移群集中运行Windows Server 2008 Enterprise 64.目前有两台Web服务器和两台数据库服务器。 我期望完成的是： 自动冗余故障切换，如果负载平衡器发生故障。 无需中断用户即可将Web服务器无缝地从负载平衡组合中进行维护。 我不确定这是因为我们的应用程序的工作方式 – 用户倾向于说，login到应用程序的整个转变。 根据需要扩展Web服务器的能力（不需要现场完成）。 这是一个纯粹的微软商店; 所以不幸的是标准的Linux工具不适用于我们。 我曾经尝试过： 微软的NLB（networking负载平衡服务） ：这个方法对于一个简单的解决scheme来说效果相当好，因为它只是在Web服务器上运行，所以相当具有成本效益，但是我还没有find使这个服务符合上述要求的方法。 每当我们试图从负载均衡混合中取出一个系统时，向负载均衡的url / ip发出请求的客户端仍然试图被引导到离线机器。 这可能会造成巨大的问题，特别是考虑到我们的用户将通过这些系统提交客户付款。 也许我们在这里做错了什么 该devise： 那么，考虑到以上所有，Microsoft NLB是唯一的答案吗？ 还是有更好的工具可用于我们的情况？ 编辑4/21/11 感谢您的快速反馈。 只是为了澄清几点： 这些是Intranet Web服务器 。 他们不接触互联网。 永远。 说服我的老板让我部署一对Linux服务器不会太困难。 她不是Linux环境的障碍 – 这是我们的员工。 他们唯一的技能是Windows。 这将会使我的社交生活在我们的数据中心开始部署Linux服务器。 😉 我最终寻找负载均衡Web服务器的“微软方式”，同时在负载均衡子系统中提供冗余。 如果这真的是微软的NLB服务，那么…也许我应该开始一个新的问题。 🙂 如果这是一个更好（或唯一）的解决scheme，我愿意向硬件负载平衡器开放。
对不起，这样一个高层次的问题。 我了解服务器负载平衡的基础知识，但pipe理30,000台服务器的概念对我来说有点陌生。 平衡两台或三台服务器的规模是否相同？ 这与memcached，sql / mysql，search引擎等事情有什么关系？ 这是一个“控制器”服务器和从属服务器的传统系统吗？ 如何处理冗余？ 感谢有关此事的文章的任何信息或方向。 编辑感谢回复的家伙。 我的post被closures了，但是我修改了标题，希望能重新打开，因为我发现这些超级高级数据解决scheme涉及的问题解决过程令人着迷，而且我目前正在构build一个需要一些基本负载平衡，因此这个问题。
我有兴趣在Amazon EC2上构build两个具有故障转移function的容错/冗余NFS服务器。 我熟悉DRBD，Heartbeat等工具/技术。亚马逊是否提供了通过他们的平台实现这一目标的具体方式？ 一个合适的例子可能是文件保存在一个单独的冗余EBS上 – 如果发生故障，将从预先构build的AMI自动启动一个新实例，安装EBS卷，并且无缝地转换IP地址。 这可能吗？ 有没有比亚马逊更好的平台？ 你能给我一个关于我们正在讨论的基础架构的广泛的概念吗？
如果您在两台服务器上提供服务以确保高可用性，那么最好是以完全相同的方式configuration它们，而不是应该引入轻微的差异来防止“畸形configuration”错误？ 我们在Linux（Ubuntu LTS），Nginx，Apache和Python WSGI堆栈上托pipe一个基于Django的网站，在负载均衡器后面的三台服务器上复制。 目前他们被托pipe在亚马逊云，但我们可能会转移到我们自己的数据中心在未来。 我们最近在三台服务器上都遇到了一个问题，这个问题只能通过升级内核来解决，这使得我们认为这个特定版本的内核与亚马逊可能已经开始使用的物理硬件是不兼容的。 这让我想：将所有机器保持在完全相同的configuration（更容易pipe理？），还是应该保持稍微不同，以便两个组件之间的不兼容性只会在一台机器上performance出来，而不是全部他们，保持你的网站在空气中？
至less从冗余来看，行业标准是相当高的。 为了说明我的观点，这里是我目前的设置（我正在运行一个金融服务）。 每个服务器都有一个RAIDarrays，以防万一某个硬盘出现问题 ….如果服务器出现问题，则由另一台备用的相同服务器进行镜像 …而且两台服务器不能同时关机，因为我有冗余的电源和冗余的networking连接等 …和我的托pipe中心本身有两个电力连接到两个不同的能源供应商，冗余的networking连接和冗余的厕所，以防万一两个安全卫士（对不起，四）需要在同一时间使用 …万一出了什么问题（一个核武器？不能想到其他任何东西），我有另一个完全相同的设置在另一个国家相同的托pipe设施。 声誉损失的成本，如果下降=非常高 硬件故障的可能性与我的设置：<< 1％ 硬件故障的可能性较低的偏执狂设置：“1％ ASWELL 在我们的应用程序代码中发生软件故障的可能性：>> 1％ （如果您的软件从未因为缺陷而停机，那么我build议您重新检查一次您的报告/监控系统是否停止运行，甚至是SQLServer–这可以被巧妙地开发和testing有强大方法的人 – 有时会下降） 换句话说，我觉得我可以在我母亲的公寓里安置一台便宜的笔记本电脑，而人力/软件问题仍然是我的风险较高。 当然，还有其他的事情要考虑，比如： 可扩展性 数据安全 客户期望你达到行业标准 但是，将两台服务器托pipe在两个不同的数据中心（没有额外的备用服务器，除了我的托pipe设施提供的networking设备之外，还要增加一倍的networking设备），将为我提供所需的可扩展性和物理安全性。 我觉得我们正在达到一个冗余只是一个沟通工具的地步。 老实说，99.999％的正常运行时间和99.9999％的正常运行时间之间的差别是什么，当你知道由于软件错误你会下降1％的时间？ 你多大程度上把你的冗余疯狂？
我正在构build一个正常运行时间很关键的Web应用程序。 我明白，100％的正常运行时间是不现实的，但我想达到五个九。 我不确定如何做到这一点的最谨慎的方式。 我的初步计划是在两个地理上分开的数据中心运行的Web应用程序。 “主”数据中心将包含主服务器，这将复制到其他地方未使用的“从服务器”服务器。 如果主数据中心发生停机，DNS故障切换会将stream量转移到“从属”服务器。 这种技术存在挑战，包括一些用户由于奇怪的DNSloggingcaching等而无法访问网站一段时间。 但是，我已经阅读了很多意见，指出DNS故障切换不是一个很好的解决scheme，您应该将所有内容都保存在一个数据中心，并将重点放在冗余。 我看到的问题是，即使是良好的数据中心似乎也有networking问题，可以导致足够的停机时间，打破五个九的期望。 我应该使用DNS故障转移选项吗？ 有更好的select吗？
任何人都可以提供SQL Server集群可用选项的高级概述，其优点和缺点？ 使用Microsoft群集服务或SQL Server本地群集更好吗？ 这个select是否适用于最新的SQL Server版本？
在服务器上将两个网卡设置为两个不同的交换机，其中每个网卡具有不同的IP（但在同一networking上），然后交换机到路由器。 如何将路由器上的两个端口configuration为冗余，以便一个端口转到另一个交换机，另一个端口转到另一个交换机。 路由器是Cisco 3825，交换机是Dell Power connect 5324s。 这个想法是，只要服务器上的应用程序被configuration为与两个IP一起工作，任何1个NIC或1个交换机都可能会失败，并且服务仍然可用。 我知道路由器仍然是单点故障。 更新： 一点背景，我移动我的整个数据中心，没有太多时间来规划，所以这种冗余可能超出了我所能学习和做的时间。 但是，我将重新布线一切，也许会购买东西。 我几乎有足够的交换机将所有服务器连接到两台不同的交换机，并有一个3800和一个备用2800路由器。 如果我保持现在的configuration，但是将第二个NIC插入到每个服务器的冗余交换机中，然后将第二个NIC插入到第二个路由器中，就物理configuration而言，是否可以准备设置这种冗余？ 可能这个configuration是限制在我的冗余选项，或者我走哪条路线，这基本上是物理布局？
我希望有一个高可用性的MySQL系统，在Amazon EC2实例上运行自动故障转移。 解决这个问题的标准方法是Heartbeat + DRBD问题，但是我发现很多post提示DRBD在EC2上不起作用，尽pipe没有人确切地说明了为什么。 显然，在虚拟化环境中，连续的心跳或不同的networking是不可能的。 让不同的服务器处于不同的可用区域也是一件好事，但是我们遇到了一个非常棘手的问题 。 什么是人们对在“云”中拥有高运行时间解决scheme的看法？ 注意：这个问题是在RDS发布之前被问及的，这个问题对于今天的现代IT专业人士来说是一个很好的自动答案。 🙂