具有高可用性的CloudFoundry架构

具有高可用性的CloudFoundry架构

CloudFoundry部署交流QQ群：176302388

    在CloudFoundry的实际生产环境中，随着业务量的提高，访问量和数据流量的快速增长，附加给CloudFoundry中的各个组件的压力也会随之增大，当组件节点所承受的压力超过了其所能够承受的范围，就会出现节点宕机崩溃或者计算缓慢，解决此类问题无疑需要对应地加大组件节点的计算处理能力，一般来说，可以有两种途径：一是增加该组件节点的计算资源，如加大内存、增加CPU等，这是纵向扩展；二是额外增加具有相同职责的组件节点并通过负载均衡处理以分担原组件节点的计算压力，这是横向扩展。CloudFoundry整个平台组件节点众多，哪些组件节点适宜做横向扩展，哪些组件节点适宜做纵向扩展，这需要根据节点的具体职责进行分析。下图为笔者画的一幅架构图，至于为何如何设计，后边一一分析。

负载均衡器

本方案中的负载均衡采用Nginx+keepalived组合，Nginx在前端提供负载均衡及静态页面缓存，必须保证其高可用性，所以配置两台Nginx服务器做主备，外加keepalived来实现故障自动切换，如果觉得这还不保险，可以再复制一套该配置，域名同时解析到两个VIP上。

路由集群

Router节点是CloudFoundry平台对外提供访问的唯一接口，一旦Router节点发生故障，所有APP应用都不能正常访问，而且该节点直接影响前端用户体验，需要提供通畅的访问支持，为了保证Router节点的高可用性，可以设置多个Router节点，未发生故障的情况下，负载均衡服务器将访问请求分担到各个router上进行处理，增强用户体验，而在某个router节点发生故障的情况下，负载均衡器会自动将访问请求发送到其他正常运行的router节点。

控制节点集群

Cloud Controller节点是整个CloudFoundry平台的核心节点，CC节点一旦发生宕机故障，整个CloudFoundry平台除了直接与Router交互对外提供APP访问的DEA服务正常以外，其他所有服务如状态监测、APP管理、故障自动恢复等都不能正常进行，因为这些服务都需要CC节点的Rest API提供支持，所以设置多个CC节点，未发生故障的情况下，router会将访问请求分担到各个CC上进行处理，而在某个CC节点发生故障的情况下，访问请求将被发送到其他正常运行的CC节点进行处理。

Health Manager集群

HM节点负责APP状态监控及管理，在APP状态异常的情况下，驱动CC节点恢复APP至正常状态，是APP长时间稳定健康运行的重要组件，所以设置多个HM节点，分流APP的状态监控数据并且保证在单点故障的状态下保证对APP的监控。

数据中心

数据中心由三部分内容组成：NFS Server、CCDB、UAADB，其中NFS Server用于存储CloudFoundry平台的所有非结构化数据，CCDB用于存储平台除用户认证以外的所有结构化数据，UAADB存储身份认证的相关数据。此类涉及到持久化数据库存储的组件的高可用性解决方案很多，主要常见的就是HA热备，通过数据冗余保证数据的安全性，此外，对于此类无法进行横向扩展的组件，应进行适当的纵向扩展，保证其物理资源充足并且健全。

身份认证服务集群

UAA节点为CF平台提供身份认证及授权服务，同样是CloudFoundry平台的核心组件，因为很多操作都需要通过身份认证，所以必须保障该节点的高可用性，通过设置多个UAA节点，对身份认证请求进行分流，从而提供用户体验，也保证了在单点发生故障的情况下，其他节点能够正常工作。

DEA集群

DEA节点是App应用的最终运行环境，在CF平台中，占用资源最多的就是DEA节点，根据实际运行的App所需要耗费的资源进行相应部署，保证DEA集群的资源能够支持App应用的正常运行，多节点的DEA集群部署是毋庸置疑的，因为即使在尽力纵向扩展的前提下，单节点的DEA基本也不可能达到多App应用对计算资源的要求，另一个方面，多节点的DEA，也能够支持App多实例分布式部署，避免出现因为单点故障因为APP无法访问的情况。

服务中心

服务中心是对所有第三方服务的一个总称，包括redis、mysql、memcached、mongodb等，实际运用中，可以根据service的重要性来决定如何进行部署，如需要高可用稳定运行的redis服务，那么可以考虑redis_gateway节点+redis_node主备模式。

可选部署

Loggregator是CloudFoundry中用于对App日志收集的组件，并可以对接其他的日志组件，根据实际运用中对App日志的重要性分析决定配置方案，若App日志很重要并且要保障其高可用性，那可以配置多个Loggregator节点，Loggregator节点的运行状态并不影响CF平台其他组件的运行情况，所以该节点也可以不进行部署或者单节点部署即可。Collector组件是用于通过NATS消息总线发现其中注册的其他组件的信息、可以通过healthz和varz来收集对应的信息并进行发送，如对接专业的数据分析系统如Datadog、AWS_Cloud_Watch等。Syslog即syslog_aggregator，用于收集其他各个组件的日志信息进行集中查阅。Collector和Syslog都不需要也不支持多节点部署，其运行状态也不会影响CF平台其他组件的运行，纯粹作为附加信息查阅组件存在，所以无需保证其单节点故障情况下可用，若对日志信息等比较重视，可以通过纵向扩展提高可用性。

NATS

NATS是消息组件，该节点发生故障的情况下，会影响其他组件中通过NATS消息总线传输数据，但是不影响APP的所有运行环境，高可用的NATS依赖于底层IAAS环境的高可用性，可以通过纵向扩展提高NATS的可用性。