Tuxedo负载均衡及多域环境的测试.doc

Tuxedo负载均衡及多域环境的测试Author:robertb9527(老康)E-mail:Homesite:Date:2006.10.161. Tuxedo简介BEA Tuxedo是当今C、C+和COBOL解决方案的首选平台，是许多全球领先公司的事务处理支柱，运行着一些规模最大的关键事务处理系统，如有线传输、ATM和电信等。作为一种多语言、可扩展的事务处理平台，BEA Tuxedo为机构提供了任务关键型基础架构，能改善已有应用的可访问性，整合企业事务和消息传输解决方案，能通过XML Web服务支持核心应用，能提高企业的生产率、效率和敏捷性，使IT机构能更好地与业务流程保持一致。BEA Tuxedo是在企业、Internet这样的分布式运算环境中开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。它具备分布式事务处理和应用通信功能，并提供完善的各种服务来建立、运行和管理关键任务应用系统。BEA Tuxedo使分布式关键任务应用系统具有大型主机的性能，从而使这些应用系统能够应付数以万计的用户，大交易吞吐量，多并行数据库存取和大量数据，同时保持较短的反应时间，较高数据完整性和安全性，并且确保系统可用性。2. Tuxedo特点1、通过在分布式网络复制应用服务以及在所有可用资源间平衡负载，最大限度地提高可用性和吞吐量；2、多层架构优化了跨异构环境的事务，提高了处理效率，完善了资源管理；3、充分利用已有技能和资产，降低总拥有成本；4、基于标准的强大API简化了事务处理和基于消息的应用开发，并提供了强大的可扩展性和基于标准的互操作性。BEA Tuxedo是所有非Java应用的关键组件。它与BEA WebLogic Server共同作用，提供了一个端到端语言支持基础架构，并将企业应用连接到BEA AquaLogic服务基础架构层，从而全面支持SOA。BEA Tuxedo可以通过WebLogic Tuxedo Connector与BEA WebLogic Enterprise Platform协作。这个高速连接器能支持全部事务和安全性传递功能，使企业能构建无缝的端到端解决方案。3. 本文摘要Tuxedo负载均衡是指在同一个域中，可以实现对这个域中的多台机器进行负载量的平衡，使多台机器协同工作同时对外提供服务，客户端请求call其中任何一台机器的效果均相同。客户端的请求上来之后，Tuxedo多机负载均衡机制会自动协调，由其中负载最小的一台机器上的服务来处理这个请求，这样多台性能一般的机器组合在一起也能提供相当强大的服务。本文中的多域环境测试研究了两个域之间的直接服务调用，即实现这样一种模式：客户机client端直接通过tpcall国家前置server，在国家前置的server中直接tpcall世界中心主机，实现多域模拟。另外在配置这些功能的同时，对Tuxedo配置文件中的一些参数也进行了测试，最后还验证了一下远程主备域的自动切换。4. 关键字Tuxedo，负载均衡，多域，主备域5. 名词解释BBL：Bulletin Board Liaison，电子公告牌DMADM：DomainConfigurationServerGWADM：DomainGatewayGroupServerGWTDOMAIN：负责响应域间通讯MSSQ：MultiServer,SingleQueueMP：多机模式，多台物理机器对外提供服务SHM：单机模式，只有一台机器对外提供服务WSL：Workstation Listener，起指定的监听端口WSH：Workstation Handler，由WSL所fork出来专门处理客户请求的进程6. 测试环境配置为了在有限的条件下对多机负载均衡与多域环境均能进行测试，配置如下：6.1 主机节点系统最少要求有4台机器，1台模拟世界中心主机，2台模拟国家前置主机，还有1台模拟客户机client端。主机节点系统环境如下：服务器A(世界中心)：操作系统：Linux RedHat 8.0（内核版本2.4.18-14）CPU：PentiumIII863MHz，catch256KB内存：256MB交换分区：512MB服务器B(美国前置)：操作系统：Linux RedHat 8.1（内核版本2.4.18-14）CPU：PentiumIII600MHz，catch256KB内存：256MB交换分区：512MB服务器C(中国前置)：操作系统：Linux RedFlag 4.0（内核版本2.4.21-9.30AX）CPU：PentiumIV2.8GHz，catch512KB内存：1GB交换分区：2GB客户机client端：操作系统：WindowsXP SP2CPU：PentiumM1.4GHz内存：512MB6.2 网络环境网络环境配置如下：服务器A模拟世界中心主机在域world中；服务器B模拟美国国家前置主机和服务器C模拟中国国家前置主机在域country中。7. 安装配置7.1 负载均衡的主机端安装1、多机负载均衡主机端需要两台机器，如上面环境中说明的服务器B和服务器C。2、操作系统、Tuxedo8.1、cc编译环境按要求安装。3、编写简单的服务器端程序，一个将前台送上来的字符转换成大写字符，见附录1；另一个将送上来的字符转换成小写字符，见附录2。server名分别为simpsvrUp，simpsvrLow， services名分别为TOUPPER和TOLOWER。4、B机IP地址：2，C机IP地址：35、配置ubbmp：见附录3配置完成后用tmloadcf y ubbmp生成二进制文件tuxconfig。6、分别在B机和C机上起tlistenB机上：tlisten l /20:8888C机上：tlisten l /21:8888启动完tlisten后在B机上起服务：tmboot y7、B机上服务起来的时候，通过tlisten会自动按照ubbmp中的配置把C机上的服务拉起来。无论在B还是在 C机通过tmadmin看到的东西是一样的，对外它们是一个整体，无论是访问B机上的服务，还是C机上的服务，都是相同的效果，如果B机没有，它会自动从 C机寻找。7.2 多域环境的主机端安装1、多域后台环境的建立，至少需要两台机器，这里我们用服务器A和服务器B。2、操作系统、Tuxedo8.1、cc编译环境按要求安装。3、服务器端程序，B机我们模拟美国国家前置，写一个服务接收前台送上来的数据，然后直接tpcall到A机上的服务，B机server名为simpsvrUp，services名为TOUPPER；A机名为simpsvrLow，services名为TOLOWER。4、A机虚拟IP地址：1，B机虚拟IP地址：25、配置ubbdm和countrydom ：B机ubbdm文件内容见附录4，配置完成后用tmloadcf y ubbdm生成二进制文件tuxconfigB机countrydom文件内容见附录5，配置完成后用dmloadcf y countrydom生成二进制文件bdmconfigA机ubbdm文件内容见附录6，配置完成后用tmloadcf y ubbdm生成二进制文件tuxconfigA机worlddom文件内容见附录7，配置完成后用dmloadcf y countrydom生成二进制文件bdmconfig6、B机和C机上tmboot y启动各自的应用。7.3 客户机(Client端)安装安装LoadRunner8.0，启动Virtual User Generator创建虚拟用户，选择tuxedo6类型，并且编写脚本见附录8。8. 验证测试8.1 负载均衡性能测试8.1.1 过程后台运行bang程序，参见附录10，对服务器进行压力测试，单机和多机模式下都运行3次。方案一：后台服务程序执行简单操作返回，复杂度很低。1、单机模式SHM，单独使用B机：2、多机模式MP，B机和C机同时工作：方案二：增加后台服务的复杂度，使其处理一笔交易的时间加大，并且后台处理请求时sleep(1)秒。1、单机模式SHM，单独使用B机：2、多机模式MP，B机和C机同时工作：说明：无论单机还是多机模式下，后台服务在不同压力下自动起停情况：不设置自动起停：MIN=5 MAX=10，不管压力多大，一直保持5个server；设置自动起停：MIN=5 MAX=10，随着压力的增长，server的个数自动增长，直到10个。8.1.2 结论先对上面两种测试方案作个总的概括：方案一：在后台服务处理复杂度很小的情况下，队列不会堵塞，有交易发生就马上处理掉，TPS完全取决于网络速度和CPU速度。所以不管是用单机SHM，还是多机MP都看不出什么差别。方案二：在后台处理的时候加上了sleep(1)，这样就导致很多服务都堵在那里，消息队列也堵塞得很厉害，平均长度达到9左右。在这种情况下如果是单机SHM的话，处理能力相当有限，虽然服务从起初的5个自动增加到了10个，但是TPS最多也就10笔。而在多机MP下，压力可以分摊到另外一台机器上，两台机器协同处理。每台机器服务数都从起初的5个自动升为10个，TPS也增长了1倍达到20个。于是从上面的测试结果可以得出如下结论：1、使用多机模式的好处显而易见，就是可以将压力负载分散到其他机器上，提高了系统处理客户请求的性能。另外的一个特点是，就算一台机器的某个服务有问题，如果另外一台机器上也有这个服务，客户端也能call到该服务；2、单机处理能力是有限的，而且一旦机器出现问题，系统就不能正常运行；3、在多机模式的配置文件中如果每台机器的服务部署都是一致的话，那么底下的客户端无论连接哪个后台都能得到同等的服务；4、对于服务自动起停的验证，在测试中随着压力的不断上来，就会自动增加服务个数，直到压力下来，服务又会自动减少服务的个数。这样就充分利用了机器资源，减少不必要的浪费；5、多机模式还有一个特点就是所有服务的起停，都是通过一台master机器所完成。虽然物理上是很多台机器，但是逻辑上看上去就像一台机器。8.2 多域环境性能测试8.2.1 过程1、多域环境可以将部署在几个地方的Tuxedo服务相互联系起来。也就是在A域里能看到B域里的服务，然后就能直接调用B域中的服务。2、本文的测试中涉及到了多个域的操作：客户机call国家前置，国家前置再直接call世界中心。3、客户端我们用loadrunner虚拟用户并发调用国家前置服务(B机)，同时在该国家前置的服务里又调用世界中心的服务(A机)。4、以下是在loadrunner测试的一些结果，10用户并发情况:8.2.2 结论1、由于测试主机性能的问题，虽然上面测试的处理速度达到了100笔/秒，但是这并不是理想的情况，后来直接在后台写了一个bomb程序不断fork子进程来call主机服务，通过查日志发现能达到了500笔/秒的速度。2、验证多域的连接和交易的跑通都没有问题。3、测试中发现国家前置可以起多个服务，处理loadrunner发上来的并发请求一点不感到吃力，问题在于中间负责处理转call世界中心的服务GWADM和GWTDOMAIN处理有瓶颈，后来通过查资料发现可以起多对GWADM和GWTDOMAIN对，于是瓶颈问题也可以得到解决。4、多个远端备份域：无论是国家前置还是世界中心的多机环境都可以有几个备份，分布在不同的域里，一个是主域，其他是备份域。当本地域与主机的远端域连接失败时，本地域将请求转发到另一个备份的远端域上。当主域恢复正常时，本地域可以将请求转发回主域。但是要注意 CONNECTION_POLICY必须配置成ON_STARTUP或者是INCOMING_ONLY。例如配置文件中:*DM_REMOTE_SERVICES为DEFAULT:RDOM=B1,B2,B3TOUPPER当本地call远端TOUPPER时，如果连接域B1失败，则自动连接域B2，甚至域B3，这样系统的可靠性就得到了保证。9. 参数说明9.1 CLOPT参数举个例子说明清楚一点：在ubb文件的*SERVERS字段中，有如下配置WSLSRVGRP=ADMINSRVID=1CLOPT=-A-t-n/2:6666-m10-M100-x5-A参数表示启动的时候WSL将提供所有服务，这是默认的。-t参数在“”之前的-t参数，表示前台client是低版本，如果前台Tuxedo版本比后台低，后台一定要加上该参数，否则前台call不到后台的服务。-m参数这是WSL最少会folk出来的WSH进程个数(初始个数)，值从0到255.-M参数表示这个WSL最多会folk出来的WSH进程个数，测试发现该参数太小会严重影响处理能力。-x参数表示每个WSH同时处理多少个client端连接(请求队列长度)，测试发现该参数太小也会严重影响处理能力。9.2 SERVERS字段的参数这里也举个例子说明：在ubb文件的*SERVERS字段中，有如下配置simpsvrUpSRVGRP=REMITSRVID=10RQADDR=RQ_simpUpRQPERM=0666CLOPT=-A-p1,10:2,1MIN=2MAX=10其中simpsvrUp是服务名，SRVGRP是组名，SRVID是服务ID这个例子主要是说明Tuxedo在负载均衡的时候，自动起停服务个数的配置。以下是相关的参数：-p 1,10:4,1 表示请求队列中有超过4个请求，且持续时间超过了1秒钟，则增加一个该服务，请求队列中小于1个请求的，且保持了10秒钟，就自动减少一个该服务。-p参数的原型是-p Llow_water,terminate_time:high_water,create_time如果MAX1，并且使用了MSSQ(RQADDR，RQPERM)的Server可以配置-p来控制进程的增加和减少。控制方法如下：如果请求队列中的请求个数大于high_water后超过create_time秒, 就增加该服务的一个新进程；如果请求队列中的请求个数小于low_water后超过terminate_time秒,就停止该服务的一个进程。low_water缺省是平均每个服务进程有一个请求消息或者workload 50；high_water缺省是平均每个服务进程有两个请求消息或者workload 100。create_time缺省是50，terminate_time缺省是60。MIN是该服务最少会起的个数，MAX是该服务在满足增加服务条件后就自动增加，但是不会超过MAX个。RQADDR是Request Queue消息队列名。RQPERM是消息队列的权限。9.3 几个重要时间参数SCANUNIT是BBL在所有服务请求中定期扫描以寻找超时的交易和被阻塞的调用的间隔时间(秒)。这个参数指定 BBL扫描间隔时间的基本单位，它会影响在tpbegin中指定的交易超时时间和用BLOCKTIME指定的请求阻塞超时时间的精确程度。 SANITYSCAN，BBLQUERY，DBBLWAIT，BLOCKTIME等参数都是SCANUNIT的倍数，而不是实际秒数。而作为时间单位的 SCANUNIT必须是5的倍数，并且满足060。SANITYSCAN的值指定在每个MACHINE上BBL自动检测所有进程的时间间隔，以SCANUNIT为单元。缺省值满足SCANUNIT*SANITYSCAN约为120秒。DBBLWAIT的值指定DBBL扫描BBL时等待所有BBL应答的最大时间，以SCANUNIT为单元，即超过 DBBLWAIT*SCANUNIT(秒)就超时。每一次DBBL将请求转发给它的BBL时，BBL会在请求返回结果之前先回复一个肯定的应答。这样可以定时检测死掉或不正常的BBL。缺省值满足SCANUNIT*DBBLWAIT的值等于SCANUNIT和20秒两者之间的最大者。BBLQUERY指定DBBL对所有BBL进行状态检查的时间间