我们有2台Windows Server 2008 R2。这两款电脑都安装了带有Web应用程序的glassfish。第一台PC(PDC)的IP为192.168.1.7,第二台PC(BDC)的IP为192.168.1.8,用户使用ip 192.168.1.7登录应用程序。
我们想要做的是如果pc用户无法使用ip 192.168.1.7访问应用程序,那么使用192.168.1.8而无需用户做任何事情。
我们发现你可以用glassfish来做,但它使用apache作为中介。如果具有apache的pc失败,则无法进行故障转移或使用该应用程序。我们也看到我们可以使用EasyDNS使用域名来实现,但是网络没有互联网访问权限,所以我们也放弃了它。
有没有办法在不依赖互联网或中央电脑的程序的情况下进行故障转移?
答案 0 :(得分:1)
需要一种方法来接收一个共享IP地址上的请求,并将它们分布在多个节点上(负载平衡/高可用性故障转移)。
可选地,可以在LB / HA和后端服务之间分层中介功能,例如卸载静态内容,某些类型的请求过滤等。
对于LB / HA,通常使用
在你的问题中,你不清楚你打算用Apache超越冗余解决什么问题,它通常无法解决,因为它本身往往是单点故障。 IIS具有相同的困境,其中ARR add-on经常用于向后端服务器进行反向代理,但本身就是单点故障。就像Windows有NLB为几个配置相同的服务器(例如Java服务器,带有ARR节点的IIS,Apache节点)提供冗余链接一样,Linux上的Apache也有described here等机制。
但是,这些功能并不像使用专用的专用负载均衡器来支持后端服务器和可选的IIS / Apache /其他前端Web节点那样功能丰富且高效。此外,他们倾向于创建自己的问题域,这限制了功能集并创建了额外的依赖性复合体。简而言之,除非设置非常简单,否则它们往往会过度消耗维护/开发时间。
共享同一磁盘的群集服务(例如评论中建议的)通常不用于Web冗余方案,因为它们可以更好地解决其他设计问题(例如高可用性文件或打印服务)。使用本解决方案中讨论的Web冗余技术的一个原因是一个维护可以轻松地回收节点,另一个是可扩展性因素,等等。与群集解决方案相比,唯一的缺点是它们无法跟踪用户状态。但是,由于群集解决方案通常专门用于保持用户会话感知的特定实现,而Web交付解决方案具有广泛的会话感知分布,因此这种论点在大多数情况下都没有用。
使用DNS之类的外围服务进行故障转移往往被认为是有充分理由的怀疑,因为除了少数例外情况(例如mx-pointers)之外,并没有考虑到这种情况。特殊变体可能仍然受到常用的DNS子系统中内置的广泛缓存的影响,并且在这种设置中形成弱链接。
如果符合以下条件,仍可考虑使用DNS作为主要冗余机制:
提供LB / HA逻辑服务器端的替代方法是将其构建到客户端。