翻译自Sean Wilbur’s blog文章Scaling IBM UrbanCode Deploy
摘要
使用IBM UrbanCode Deploy（UCD）来提高组织的软件持续交付能力是一个很好的开始，但是在这条成功的路上我们还会遇到一个问题。因为UCD管理着组织的应用部署过程，所有的应用部署都将依赖于UCD服务器的可用性和执行能力，所以我们必须考虑如何使UCD满足生产应用的需求。这里将讨论如何设计和架构一个有故障切换和灾难恢复能力的，可扩展的UCD部署方案。
高可用性和灾难恢复
如何区分高可用性和灾难恢复？这里我们所说的高可用性，是指跨多个服务器或数据中心的水平扩展能力，提供一种手段来增加容量或为停止服务或故障的UCD服务器增加容错能力。而灾难恢复解决方案，旨在应对灾难性故障或吸烟孔（Smoking Hole）场景，即整个服务器或服务器群集不可用。灾难恢复通常是大型和小型组织的业务连续性计划的一部分。在对数据中心的可靠性和现有的物理/虚拟机的冗余度做整体提升时，灾难恢复解决方案可能是必要的。而在本文，我们将主要围绕大家更感兴趣的高可用性进行讨论。
IBM UrbanCode Deploy子系统
我们将从UrbanCode Deploy的整体架构出发，来设定上下文背景。关键的是，本文的解决方案是专门为处理大规模应用部署（即部署目标服务器在1000台以上）而设计的。
上图中显示的主要子系统有：Web用户界面，工作流引擎，服务器/代理机通信，工件和文件管理子系统。我们将看看如何针对每一个子系统进行扩展。
Web用户界面
配置Web子系统是服务器的Web前端，也是客户访问部署配置和触发部署的接口。应用的这一Web层提供了一组RESTfull API，被Web用户界面，UCD客户端以及API用户共享调用，与UCD系统进行交互。
作为一个基于Web的解决方案，该子系统可以被扩展，用以处理更多的并发访问，并使用HTTP负载均衡进行UCD跨多服务器集群的横向扩展来提高吞吐量。
这个解决方案需要您激活集群，并且整体的系统性能主要依赖于底层的共享数据库和文件系统的性能。
工作流引擎
工作流子系统，负责在所有的部署目标服务器间统筹部署，这包括部署任务的分发，在代理机上执行部署，以及在执行时持续处理从代理机处收取到的更新信息。
随着被管理的代理机数目和并发部署数目地增加，处理的数据和时间也随之增长。单一的UCD服务器能够处理上百个这样的并发事务，并有可能通过增加服务器的处理能力来增强UCD的并发处理能力。但是在某一时刻，更实际的解决方案将是利用集群，在多个UCD服务器之间分担负载。
上图的解决方案,使我们能够在UCD服务器集群间分散负载来提高吞吐量。在这里，我们利用JMS网格（JMS Mesh）技术在服务器之间共享数据信息。这里需要注意的一点是，在使用HTTP负载均衡时，我们不能用一个负载平衡器仅仅指向一个共享的URL。由于服务器和代理机之间的连接是持久的，我们推荐使用Round Robin DNS来实现负载均衡。
服务器/代理机通信
由于代理机的分布性和所需的持久连接的规模需求，代理机的数量将远远超过服务器的数量。 UCD提供一种模型，使用代理中继器（Agent Relay），为代理机提供到服务器的本地连接端点。这既可以用来减少被保持在服务器上的打开连接数，还减少了需要连接到UCD服务器的代理机数目。使较少的代理机直接连接到服务器，不仅可以简化您的安全规则，并且像今天很多企业在生产环境中使用的“堡垒机”一样，还可以用来向隔离环境或者非可信环境中实施部署工作。
该模型已被证明可以成功伸缩扩展到数千台代理机，并且理论上可以扩展到上百万台。它提供了一种有效途径，利用共享的持久连接，将一个服务器线程映射到一个代理中继器，而不是一个代理机。
工件库的伸缩和分发
工件子系统是我们重点讨论的最后一个部分，它负责存储和版本化可部署的工件。如我们所知，文件系统的备份和共享是集群环境中伸缩扩展的关键，也是之后我们会谈到的灾难恢复解决方案的关键。建议您将UCD服务器连接到快速SAN存储上，以减少在代理机上获取插件和待部署工件的时间延迟。
在UCD 6.1版本中，其中一个新功能就是围绕工件库的优化，来帮助减轻一些分发延迟。
需要注意的是，上图的模式增加了代理机与代理中继器通信的一个新的安全需求。在这种情况下，JMS已经使用了一个端口（默认为7916），HTTP代理占用了一个端口（很可能是20080），但新的工件缓存为代理中继器增加了一个新的HTTP代理端口（20081）。缓存的目的是为工件提供本地副本，来尽可能的避免服务器做重复的文件传输。在配置过程中，你可以指定代理中继器的缓存大小，这取决于你的环境。这可以有效的节省你的带宽，尤其是当你向一批代理机部署相同的工件版本时。同时这也将是在你的UCD部署架构中采用代理中继器的另一个很好的理由。
灾难恢复
灾难恢复是应对一种特殊的情况，即我们认为原来的服务器上没有任何资料幸存下来。让我们暂且忽略，可以通过一些技术手段来减少对灾难恢复的需求，比如建立UCD服务器集群，跨两个或多个数据中心架设数据库和共享文件系统。
当灾难恢复事件发生时，使UCD恢复正常工作，我们只需要一个很短的清单。
- 数据库
- 资产库文件系统
- UCD的安装配置目录
- 一个新的服务器或者集群来运行UCD
- UCD许可证
- 网络交互的安全策略，涉及HTTP/HTTPS, JMS, JDBC以及许可证通信
- 一个DNS转换器
在实际操作中，你要确保至少有夜间数据库备份，并保存了数据库事务日志来恢复数据库到故障前。文件系统应该以最接近实时的方式进行同步和复制，大多数SAN设备已经提供了类似的功能。新的服务器可以是预先准备好的生产环境的虚拟机副本，也可以是临时建立的。在新的服务器上，你需要使用之前备份的UCD服务器配置，这包括与客户机通信的SSL秘钥以及保存在数据库中的安全属性设置。有一件事很容易被忽略，那就是运行UCD所需要的许可证。这种情况我们看到过多次，所有的应用部署任务的执行都因为没有许可证而失败，这使我们恢复服务器正常运行的所有美好计划都变成了徒劳。所以我们要确保有生产环境的许可证备份可以用。
安全策略也是一个需要注意的点。所以你需要确保在断电断供时，能从生产环境服务器和灾难恢复站点服务器上获取到必要的各种终端上的策略。最后，建议你使用统一的组织命名管理规则来为DNS转换命名。
灾难恢复方案的测试也是必要的。我们推荐你在一个隔离的网段中进行测试，这样你就可以模拟一个真实的DNS接入，确保服务在不需要更新代理机/代理中继器的情况下也能重连。但如果你想在同一个网络上进行测试，则有一些事项需要注意。你无法针对你的全局DNS接入进行测试，所以你需要寻找其他的方式来验证。此外，你得小心设置UCD服务器的URL，你向服务器发送的指令和测试动作的反馈都是通过此URL来传递，一定小心不要将你的测试重定向到生产环境中。所以你需要查看UCD的系统>设置页面确保服务器站点URL是正确的指向了你的测试环境。
真实世界的部署
首先让我们从一个UCD部署架构的原型开始。这个原型可以不断被伸缩和扩展。对于Round Robin DNS和负载均衡器，目前我们可以使用一个负载均衡器来同时做到这两点，但是需要我们了解如何使用Round Robin和持久化连接，并且不要尝试分担任何一种SSL的负载。因此，负载均衡，或为JMS使用负载均衡器都是官方不支持的。但你能够通过使用Round Robin DNS，并有效结合你的负载均衡器，来完成此项工作。
部署实例#1很好的说明了上面谈及的各种部署策略
部署实例#2逐渐成为趋势。因为在被IBM收购后，UCD被越来越多的企业用户用于更大规模的部署。你可以看到集群的增加和代理中继器层的冗余设置。
何时进行伸缩扩展
仅使用单一的UCD服务器和几个代理中继器，不需要任何调优，就可以支持数百台服务器，每天几十次的部署。但是要满足企业部署规模，性能和稳定性的需求，最终还是要依赖UCD集群的实施。决定是否使用集群要基于多种因素的考虑，首先是企业愿景，然后是当前状态。
建议你考虑开展一个规划活动，来确保你有能力满足未来的部署需求，特别是考虑到你的业务持续性计划中所涉及的可用性，性能，以及可靠性等方面的需求（例如使用UCD部署生产门户网站，UCD是否也需要满足相同的可用性需求）。这是为了了解目前的使用量，以及在未来6个月，再到明年的增长预期。我建议将这个规划活动做为年度协调活动的一部分，以确保你能完成目标。大多数组织做年度预算时都会这么做。
其次是对不断变化的环境作出反应。这是一个DevOps的世界，如果你开始生产一系列新产品或在尝试不同的技术以转移工作负载，那么你现在的解决方案在3个月后可能会完全不同。因此，确保你有标准的针对UCD的应用监测是至关重要的。这样，你在第一天的时候就可以开始收集一些简单的指标，如CPU利用率，内存使用率，磁盘利用率，磁盘IO，网络IO，数据库增长率和数据库CPU利用率等。你的这些部署负载特性将依赖于组织的部署流程建立和使用。但通过识别标准服务器的高水位标记，和了解上面讨论到的UCD子系统后，识别出哪些是瓶颈，哪些是扩展伸缩中可能面临的问题，就可以确定出你的详细路线图。
总结
了解如何增强您的UCD解决方案，满足您最终用户的需要是成功部署UCD的关键。支持开箱集群和数据库群集的使用，并结合有最佳实践的解决方案，使UrbanCode Deploy在企业级部署自动化领域中占有举足轻重的地位。虽然，保持服务器运行和正常工作只是这其中的一部分，但是这部分至关重要，所有我们要确保有一个完备的UCD部署计划。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
