概述
一个高可用性的CAS部署是针对各种故障模式提供弹性的一种部署，这样即使失败了，CAS仍然提供SSO服务。我们提供了一个建议的体系结构，它提供了规划和执行CAS部署的起点，以满足机构性能和可用性需求。它还提供了一个框架，用于理解HA考虑因素对CAS软件组件的需求。
CAS的高可用性(HA)配置是通过确保有足够的冗余来实现的，以便在组件故障的情况下服务是健壮的，并且可以在没有服务停机的情况下进行日常维护。这可以通过多节点实现，也可以通过具有高级虚拟机功能的单节点CAS实现。本文档将重点介绍实现HA所需的CAS服务器组件。对HA配置的更多定量分析依赖于支持基础设施和服务，并且超出了本文的范围。
CAS服务器软件有着非常可靠的记录。然而，CAS服务器只是软件和硬件的一小部分，身份验证必须顺利地进行。集群通常被部署人员使用，不仅用于负载处理，而且也用于故障转移。即使不发生故障，有时也需要重新启动服务器。例如，如果安装了操作系统级别的严重安全修复，服务器应该立即重新启动。在一个CAS服务器集群中，即使在最忙的时候，也可以轻松地进行重新启动。
传统上，运行单个服务器会延迟这样的重启，直到不那么繁忙的时候，同时运行一个已知的漏洞。然而，近年来随着虚拟机技术的日益接受和其固有的冗余和容错，单节点CAS已经能够实现类似的质量。
Recommended Architecture (推荐的结构)
值得指出的是这个体系结构的一些重要特征:
- 依赖系统可以容忍N-1节点故障。(其中N是节点的总数。)
- CAS本身可以容忍N-1节点故障。
- 缓存节点的丢失不会导致在复制缓存中丢失SSO状态数据(即票据)。
- 缓存节点的丢失可能会在非复制缓存中导致SSO状态数据丢失(例如memcached)。
- SSO状态数据的丢失总是很优雅:用户只需重新进行身份验证。
在详细讨论推荐架构的各个方面之前，我们提供了一个指导原则，以规划一个高度可用的部署:
经验表明，简单性是成功和健壮的HA部署的重要系统特征。追求简单，你就会得到很好的服务。
Deployment Scenarios(部署场景)
单节点CAS, HA VM基础设施。
通过在复杂的虚拟化环境中运行单节点CAS，可以实现高可用性。这种高可用性的方法很有吸引力，因为它简化了CAS服务器的配置，但是需要硬件虚拟化技术，而这些技术可能不存在。
在单节点VM体系结构中，CAS服务器以及必要的先决条件和软件依赖项部署在一个主机VM中。在此部署场景下，默认的内存中注册表是足够的，不需要Servlet会话复制。这简化了部署配置，如果VM基础设施足够满足HA和可伸缩性需求，则建议采用这种方法。
真正的零停机维护(即对终端用户没有明显的影响)是无法通过这种配置实现的。然而，通过利用大多数VM基础结构的克隆能力，可以不停机地进行维护和升级。一旦新的CAS服务器节点准备就绪，就可以实现一个简短的切换，这将有效地结束所有当前的SSO会话。这可以通过在新cas.war 部署之后的低流量时间重新启动Tomcat来完成。
Multiple CAS Server Nodes
一个高可用的CAS部署由两个或多个节点组成，在一个硬件负载均衡器中处于主动/被动（active/passive）或主动/主动（active/active）模式。一般来说，前者提供了简单的故障转移;后者改进了资源的使用，降低了服务中断的成本，增加了复杂性。主动被动配置可以在主CAS节点失败的情况下使用手动或自动故障转移。Active-active配置可以使用集群的ticket registry状态，这样任何可用的CAS节点都可以为CAS服务器提供任何请求。有许多选项可用于实现具有共享票据状态的主动活动配置。
通过在多个vm或物理主机上运行多节点CAS部署，可以实现HA。这种方法很有吸引力，因为它允许在部署复杂性的边际增长的代价下实现服务的真正的零停机维护。
多节点CAS通常包含以下内容:
- 安装CAS服务器的多个实例(这样就可以在没有CAS服务变得不可用的情况下销毁一个或多个服务器)
- 配置CAS服务器的多个实例以共享ticket状态(这样，无论用户或服务与哪个CAS服务器交互，每个CAS服务器的响应都是相同的)。
- 配置一个解决方案，用于指导集群的CAS服务器之间的通信，用于检测组件故障和从服务中删除失败的组件。
- Optionally, configuring a solution for sharing session state and session failover across the CAS instances (this isn’t typically appropriate, since end-user CAS sessions tend to be short lived and the experience is more request-response style than it is session oriented) - favor short-lived sticky (aka persistent sessions) load-balancing instead (could be a problem with large NAT deployments)
- 有适当的应急计划，这样当它被执行时，就能恢复预期的防止失败的空间。(例如，有3个CAS服务器实例，集群，服务一个可以只使用两个实例的负载。)
硬件结构
物理体系结构可以通过vm或物理硬件实现。需要注意的是，在共享的ticket状态模型(Active/Active模式)中，CAS服务器节点需要能够在所有节点之间传递票证状态，因此，这些节点之间的防火墙限制需要足够的放松，以允许进行票据状态复制。
服务端点是在负载均衡器中配置的虚拟IP地址。因此，所有请求都由负载均衡器处理，然后路由到可用的CAS节点。
在CAS节点失败的情况下，可以正确地将工作负载和身份验证请求路由到另一个CAS节点。可能通过故障转移场景中,一些状态（state）可能会丢失根据用户登录流程,因此,一旦请求的重路由登陆失败的克隆节点,用户可能需要再次面对CAS登录屏幕。此故障模式可以通过Servlet会话状态复制来消除。
零停机维护的方法
维修工作，包括对软件的升级和应用，可以通过两种通用方法进行:
在主动-被动模型中，可以在被动CAS节点上进行离线工作。然后调整负载均衡器，在准备好的节点上切换，从而切换主动被动节点。这将导致所有CAS SSO会话被重置，如果在利用率高的时候完成，可能会出现一些验证失败的情况。有关此方法的更多细节，请参见下面。
在主动活动模型中，一个节点可以脱机，而至少另一个CAS服务器节点仍然存活以响应请求。完成升级过程后，服务器可以从其他活动节点获取票证状态返回到池中。某些分布式的ticket registry模型有能力通过从其他节点获取票证数据，而无需手动配置或调整。有关此方法的更多细节，请参见下面。
Active/Passive Mode
在一个主动/被动负载均衡配置中，N个节点中有1个在任何给定时间都服务于所有请求。这就简化了票据存储需求，因为在几个应用程序节点之间不需要共享票据状态。
特别地，在内存中存储ticket的默认ticket registry组件适合于活动/故障转移设置，并理解节点故障将导致ticket 丢失。值得重复的是，在应用程序失败的情况下，用户只需重新对CAS进行身份验证，就可以创建新的SSO会话;在以前的SSO会话下创建的CAS客户机会话将不会受到任何中断或数据丢失的影响
Active/Active Mode
在活动/活动模式下的负载平衡器可以同时为所有N个节点提供请求。负载均衡器选择一个节点根据配置的算法服务请求;通常是最不活跃的或循环的。在这个系统架构中，无论CAS节点请求什么，都可以使用ticket store，这是非常重要的。
讨论请求（request）的起源是很有意义的。从根本上不同的网络来源有两种相互作用:
（1）用户通过浏览器直接从CAS服务器获取一个ticket
（2）用户所访问的服务从CAS服务器获取ticket
HA Ticket Registry
以下 Ticket 存储组件提供了在易用性、可伸缩性和容错性方面的最佳折衷，并且适合于主动/被动和主动/活动设置:
转载于:https://my.oschina.net/cwzhang/blog/1819904