CF的高可用

0. 配置HA

提供冗余资源

水平扩展组件的VM, 增加同一组件的VM数量.
CF同一组件, 创建多个实例, 并且分布在不同的AZ.
每个用户的app至少2个instance

0.1 AZ 多可用区

在产品或平台升级过程中, CF中部署的虚拟机会重启. 因此会出现服务暂时不可用的现象.
将各个组件, 以冗余的方式, 部署在多个可用区. 可以保证在升级过程中, 服务不中断, 最大程度降低宕机时长.

推荐使用3个或3个以上的AZ. 组件的多个实例要分布在不同AZ之中.
只要过半的AZ可以提供服务, CF就可以正常提供服务. 类似zookeeper

0.2 垂直扩展和水平扩展

垂直扩展: 为运行CF组件的服务器增加内存和磁盘

水平扩展: 为运行CF组件增加服务器数量

垂直扩展的作用:

• app会运行在Diego cells中. 更多空间, 意味着可以运行更多的app
• CF整个集群中, 磁盘和内存空间越多, 意味着一个app挂掉后, 可以在其他的VM上重启.
• 在多可用区部署中, 一个AZ挂掉, 其他AZ将承担所有的流量, 单机性能好, 影响就越小.

0.3 支持水平扩展的组件类型

CF中的大多数组件, 支持水平扩展

原则: 组件冗余, 分布在多个AZ, 如果期望使用>3个AZ, 则AZ的数量要为基数.

HA推荐配置:

Diego Cell >=3

一定要在内存和CPU之间做好平衡, 不是越大越好
因为越大, 意味着单台cell可以容纳的app更多, 单台cell挂掉, 也会有更多的app不能正常对外提供服务
另外, 过度水平扩展, 会导致系统reblance apps时, 效率过低, 所花费的时间也越长.

Diego Brain >=2

每个AZ一个; 如果是单AZ的话, 需提供2个实例.

Diego BBS >=3

该实例数应为奇数, 等于AZ数量,或等于AZ+1数量. 每个AZ至少1个实例.

Consul >=3

该实例数为奇数, 等于AZ数量,或等于AZ+1数量. 每个AZ至少1个实例.

MySQL Server 3

MySQL Proxy >=2

NATS Server >=2

在确实缺少资源和资金的情况下, 可以部署一台NATS.
如果NATS服务器non-responsive, bosh会重新拉起一台NATS服务器.

Cloud Controller >=2

根据CF api请求数量, 以及cf中的apps的数量, 确定CC的数量.

Router >=2

根据请求量, 确定router的数量. Router越多, 可支撑的请求数量就越高.
总的来讲, Router的负载相对于Diego cell来说, 要低很多很多.

HAProxy 0或者1

对于生产环境, 最好设置为0, 使用云平台的负载均衡机制, 将router实例, 加入到负载均衡池中.

UAA >=2

Doppler Server >=2

多台doppler之间, 可以自动分担流量. 推荐每个AZ至少2台doppler

Loggregator Traffic Controller (Loggregator TC) >= 2

多个实例之间, 通过round-robin轮询, 对请求响应. 推荐每个AZ至少2台 loggregator TC

etcd >=3

该实例数为奇数, 等于AZ数量,或等于AZ+1数量. 每个AZ至少1个实例.

etcd proxy =1

不要将该组件数量设置为0, 否则有些组件将不能访问etcd服务器.

0.4 Blob存储

含义: 存储大二进制文件的地方.

推荐做法: 使用可靠的外部存储服务, 例如AWS S3,或者与S3兼容的服务.

如果使用WebDAV,或者NFS的方式, 所有的blob都是存在单机上, 并且没有办法水平扩展.

compilation实例数可以为1, 这不会影响CF平台的可用性.

0.5 支持组件的水平扩展

0.5.1 启用ops manager的resurrector

这其实是bosh提供的功能.

0.5.2 资源池

与各个IaaS平台有很大关系, 需要但多去考虑.

0.5.3 数据库

对于CF之外的数据库, 考虑使用IaaS平台提供的数据库, 更加可靠, 并且支持备份和恢复.

1. CF如何维持HA

1.1 多可用区

前提: IaaS平台支持多可用区

Diego Cell可以跨多可用区部署
跨多可用区, 部署app实例

1.2 App实例的健康管理

如果app因为某种原因挂了, CF会尝试启动新的实例, 保证正在运行的实例的数量符合容量要求.
Diego架构之下, 以下组件, 共同跟踪app的状态, 包括app的正在运行的实例数量
1. nsync
2. BBS
3. Cell Rep
当以上组件, 侦测到app实际状态与Cloud Controller已知的期望状态不符. 它们会向Cloud Controller建议start新的app实例.

1.3 处理监控

Bosh级别的监控:

PCF使用BOSH agent, monit工具监控服务器进程, 可以在虚拟机内部监控各个job的工作情况.
monit发现某个进程挂了, 会尝试重启该进程, 并且会向本机的bosh agent进行上报.
bosh agent会向bosh health monitor进行上报, bosh health monitor可能会发送告警或通知其他系统.

1.4 resurrection 恢复VMs

每台虚拟机中, bosh agent会每隔60秒, 向bosh health monitor发送心跳消息.
如果health monitor超过60秒, 没有收到某个bosh agent的心跳消息. health monitor会向Resurrector组件发送告警.
如果resurrector功能已被启用, resurrector组件会向IaaS平台发送创建新虚拟机的请求, 替换旧的虚拟机.