支持基本的高可用性¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/congress/+spec/basic-high-availability
Congress 需要支持 API 请求的高可用性 (HA)，以便即使 Congress 服务器不可用，客户端仍然可以成功地向 Congress 发送 API 请求。本提案描述了一种基本的高可用性解决方案，即按原样复制整个 Congress 服务器。每个副本运行策略引擎，包含所有表数据，并运行数据源驱动程序。
问题描述¶
目前，Congress 运行为单个独立服务器。该服务器负责处理所有 API 查询，并且是单点故障。如果服务器发生故障，将导致集成 Congress 的客户端出现停机。
提议的变更¶
- 本规范建议
复制整个 Congress 服务器
使用现成的负载均衡器将请求分发到副本，并避免故障副本
写入 API 调用会修改数据库
每个副本会定期检查数据库，以了解策略或数据源的更改
备选方案¶
更高级的设计将策略引擎与数据源分离，并将策略引擎复制 N 次，但对数据源驱动程序使用主备配置。这样，只有主数据源驱动程序与数据源通信，从而减少了数据源上的负载。数据源通过消息总线将传入的数据更改通信给副本。这种更改需要更多的代码更改来分离引擎和数据源，以及更改消息总线的工作方式。
另一种方案是将所有数据源更新发送到中央机器，该机器将预先计算所有表的物化视图。这样做的好处是可以为复制的 Congress API 提供一致性，但它依赖于单个机器来计算物化视图，并且依赖于物化视图，这会将所有中间表内容存储在内存中，这可能会消耗大量内存，特别是对于许多中间表而言。这种替代方案也需要大量的代码更改。
策略¶
无
策略动作¶
无
数据源¶
我们需要确保每个数据服务（例如 Nova 或 Neutron）可以同时接受并处理来自多个数据源驱动程序实例的请求，因为每个副本将从每个数据服务获取数据。换句话说，如果有 N 个副本，那么每个数据服务必须响应 N 次单独的数据，并且数据服务必须能够应对更高的请求负载。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
如果不同的副本为每个 API 调用提供服务，则两个 API 调用可能会返回不同的数据，因为来自数据源的数据和策略规则可能在两个副本之间不同步。每个副本检查数据库以获取更新的频率可以限制策略规则的问题，但数据偏差仍然会影响副本。
性能影响¶
此更改应该提高 Congress 服务器的吞吐量，因为可以有多个副本而不是单个服务器。但是，由于每个副本将从数据源请求数据，因此可能会对数据源产生影响。定期数据库请求以检查更新对性能的影响应该最小。
其他部署者影响¶
无
开发者影响¶
所有共享状态必须存储在数据库中，并在所有副本上定期检查。
依赖项¶
无
测试¶
启动两个副本，使用相同的数据库。在一个副本上写入策略更改，并检查策略更改是否发生在第二个副本上。
启动两个副本，并杀死一个。确保第二个副本仍然可以提供请求。再次启动第一个副本，并确保它仍然可以提供请求。
文档影响¶
我们应该添加一个描述如何配置 Congress 以进行高可用模式的描述，包括负载均衡器和共享数据库。
参考资料¶
无
