我们有一台服务器接收一些数据，充当TCP客户端，以某种方式处理数据，并将处理后的数据作为TCP服务器提供给客户端。 它还将这些数据存储在磁盘上，并可以从文件而不是实时stream中提供。 问题是这个服务必须在24×7模式下可用，不允许中断。 现在有两台服务器，一台充当热备份 – 客户端保持与两台服务器的连接，如果主服务器发生故障，他们只需切换到备份。 虽然这个解决scheme已经运行了大约15年，但是这样做有点不方便，并且在客户端上放置了很多故障转移逻辑。 最近人们开始讨论如何使用集群来确保这个服务的可用性，但是无论我多么努力地search，我都找不到任何集群解决scheme来允许透明的TCP连接故障切换，所以没有人会注意到服务器发生了什么事情。 有一些研究论文，但我无法find任何工作的实现。 这是我认为它应该如何工作： 两台服务器都通过TCP接收数据。 理想情况下，它应该看起来像一个单一的连接到“外部”的世界，以节省带宽，更重要的是，确保两台服务器接收相同的数据stream。 当一个客户端连接到集群IP时，它在单个连接中接收处理的数据，但是两个服务器都应该看到这个连接并提供数据，只是其中一个stream实际到达客户端，备份到达/ dev / null，这样说。 当服务器发生故障（一段时间不传输任何数据，例如5秒钟）时，客户端应该继续在同一连接内接收相同的数据stream。 它需要发生得非常快，所以整个stream延迟不会超过大约10秒。 可靠性在这里是最重要的。 快速故障转移是下一个。 开源的Linux解决scheme是首选，但如果存在商业和/或非Linux近乎完美的解决scheme，我也想知道它们。 强加很多限制或需要修改服务器应用软件的解决scheme也是完全可以接受的。
我们有一个现有的VMware ESX 3.5集群（6台主机，VI 2.5），需要将服务控制台移动到一个新的子网。 我们希望在没有停机的情况下为VM做这些事情。 在我以前的实验中，我发现集群networking约束检查阻止了我尝试重新configuration主机以拥有不同的服务控制台子网。 我已经尝试在所有主机的新子网中添加辅助服务控制台（使用不同的名称），并将das.AllowNetwork0设置为限制为新的服务控制台，但是如果将主机configuration为只有该服务控制台，旧的它不能join群集，但有关于不匹配networkingconfiguration的错误。 新服务控制台是否具有备用名称或匹配的名称会失败。 我们为这两个子网build立了中继连接。 我们当然可以暂时在子网上build立一个服务控制台。 所有主机上的当前configuration是（简化和编辑）： # Current service console, on port in VLAN 5 Switch Name Uplinks vSwitch0 vmnic0 PortGroup Name VLAN ID Uplinks Service Console 0 vmnic0 # connected to dedicated VMotion switch Switch Name Uplinks vSwitch1 vmnic1 PortGroup Name VLAN ID Uplinks VMotion 0 vmnic1 # Old […]
如您所见，我的两个Windows Server故障转移群集（WSFC）节点每个都有三个networking接口，将它们连接到三个不同的networking： 公共networking 由WSFC节点组成的专用networking 由WSFC节点组成的专用networking和带有WSFC Quorum Witness File Share的机器 我计划的networkingconfiguration是否合理？ 我有“正确的”数量的网卡和networking吗？ 我在想第二个NIC /networking可能是不必要的。 我的两个MongoDB副本集节点也有三个networking接口 – 非常类似于以前的情况： 公共networking 由主要和辅助MongoDB副本集节点组成的专用networking 由主，副和仲裁者MongoDB副本集节点组成的专用networking 这个networkingconfiguration是否有意义？ 我有“正确的”数量的网卡和networking吗？ 我在想第二个NIC /networking可能是不必要的。 这是我正在考虑的更简单的版本： 更新：
假设您在Windows Server 2008 R2 Enterprise上设置了由两个节点组成的Windows Server故障转移群集。 现在，当您要configuration仲裁时，您可以使用远程共享文件夹或共享磁盘（除非您的节点在地理上分开）。 我很想知道何时使用磁盘证人以及何时使用文件共享证人。 有什么区别？ 这有什么关系吗？
如何设置Ganglia，以便在群集中的某台计算机正在使用的情况下收到电子邮件，例如物理RAM的95％以上？
我正在教自己构build集群化的Java EE 7应用程序。 我专注于GlassFish Server v4.0 。 根据官方文档（第7章133页） ， Glassfish可以使用mod_jk使用Apache Http服务器进行负载平衡 。 我正在读一些关于glassfish的集群体系结构，可以用下面两张图来解释： （第二张照片来自下面的书 ） 我的问题是： 在这种情况下安装Apache的通常位置在哪里？ 它是安装在域pipe理服务器所在的同一台机器上，还是安装在它自己的独立机器上？
我注意到vnstat没有安装在CoreOS上。 有没有类似的方法来监控CoreOS集群上的networking使用情况？ 当然可以通过Docker容器运行vnstat，但是我认为只会捕获通过容器而不是整个CoreOS节点的networking活动，对吗？
我有以下设置 Oracle Solaris 10 – > 5.10 Generic_147147-26 sun4v sparc Oracle数据库11g企业版版本11.2.0.1.0 – 64位生产 Oracle Solaris Cluster 3.3u2 for Solaris 10 sparc Oracle Solaris Cluster地理版3.3u2 for Solaris 10 sparc 我使用ZFS安装了Oracle Solaris 10我有一个用于/ oradata的池当我重新启动/重新启动集群时，ZFS池因为该集群而消失无法启动Oracle数据库资源/组每次重新启动/closures集群后，我必须执行手动 zpool import db clrg online ora-rg … 可能是什么原因？ 我知道的唯一的事情就是db zpool，这个池被导入ora-has资源，我创build了如下所示（使用Zpools选项） # /usr/cluster/bin/clresourcegroup create ora-rg # /usr/cluster/bin/clresourcetype register SUNW.HAStoragePlus # /usr/cluster/bin/clresource create -g ora-rg […]
我正在寻找一个良好的configurationpostgresql复制与强大的故障转移策略（自我托pipe）。 实际上，我使用repmgr在master / slave中configuration了两个postgresql实例。 现在，我不知道在这两个实例之前应该放置什么来实现良好的故障转移。 我希望当主人倒下时，奴隶会自动向新的主人升职，而不会为客户停工。 我认为我应该把pgbool（或pgbouncer？）放在主/从postgres之前，但是为了避免把它作为单点故障，我应该有两个这样的实例，对不对？ （这是我想到的一个例子： http ： //i.imgur.com/yqky2bl.png ）。 我的根本问题是如何configuration两个不同的pgpool实例的自动故障转移。 我怎么能确定这两个改变内部主/从configuration？ 应该使用pgpool来创build故障转移或repmgr（更改两个pgpool实例的configuration）？ 我有一些怀疑，我是在正确的方式，基本上是因为我没有find关于这种types的configuration大量的文档，以及如果例如主人回来在网上可能会发生几分钟的networking问题（所以postgres不是真的下降，但它是无法由客户端）。 为了使事情更加复杂，我试图用dockerconfiguration这个基础设施（但也许可以更简单，因为我可以销毁一个pg实例，并用docker创build一个新实例）。
我们有4个Redhat盒Dell PowerEdge R630（比如a，b，c，d），它们具有以下操作系统/软件包。 RedHat EL 6.5 MySql Enterprise 5.6 DRBD 8.4 Corosync 1.4.7 我们已经设置了4路堆叠的drbd资源，如下所示： 群集群集-1：服务器a和b互相连接本地局域网群集群集-2：服务器c和d 群集群集1和群集2通过虚拟IP通过堆叠的drbd连接，是不同数据中心的一部分。 drbd0磁盘已在每个服务器1GB本地创build，并且还连接到drbd10。 整体设置由4层组成：Tomcat前端应用程序 – > rabbitmq – > memcache – > mysql / drbd 我们正在经历很高的磁盘IO，甚至到现在还没有活动。 但交通/活动会在几个星期内增加，所以我们担心会对业绩造成非常不好的影响。 I / O Useage仅在堆叠的站点（有时为90％及以上）上走高。 二级站点没有这个问题。当应用程序是理想的时候使用率会很高。 所以，请分享一些build议/调整指导方针，以帮助我们解决问题。 resource clusterdb { protocol C; handlers { pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notifyemergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f"; pri-lost-after-sb […]