如何部署 DB2 pureScale 工作负载均衡特性

Question

如题所述

Answer 1

　　DB2 pureScale 集群采用了动态的工作负载均衡分发机制，而不是传统的固定轮转 (Round Robin) 的方式。传统的固定轮转的工作负载均衡分发机制如下图所示，假如集群中一共有四个成员节点，因此每个成员节点被分配了 25% 的来自客户端应用的请求。假如每个来自客户端应用的请求对数据库资源的需求是相同的或相似的，那么这种方式是有效的。但实际的生产环境中往往每个客户端过来的请求是不一样的，假设被分配到 Member 0 上的客户端应用请求中有一个是某部门领导在查看销售报表时发起的，该操作中查询非常复杂，将访问大量的数据和消耗大量的服务器资源。如图二所示，这种固定轮转的分发机制将导致 Member 0 上压力异常的大，尽管同一时刻集群中其他的节点上的系统资源仍然很富裕。

　　为了实现 DB2 pureScale 的动态工作负载均衡，DB2 pureScale 集群中的各个成员节点会定期收集本机的工作负载信息，主要包括包括 CPU 和内存的使用情况。每个节点还会定期的从其他节点收集到 DB2 pureScale 集群中所有其他节点的负载信息。这些信息收集是由客户端的请求驱动的，只有在需要的时候才会收集。比如说，如果没有任何客户发起到 Member 0 上的连接请求，那么 Member 0 永远也不会请求收集其他节点的负载信息。但是这种情况下 Member 0 有可能被要求向集群中的其他节点提供自己的负载信息。

　　DB2 客户端在处理应用向 DB2 pureScale 集群发起的请求时，会先从 DB2 pureScale 集群服务器拿到 DB2 pureScale 集群服务器成员节点负载信息列表，然后优先将新的工作负载 ( 连接或事务 ) 分发到 Priority 高的成员节点上。

　　可以用 db2pd 工具查看当前 DB2 pureScale 集群中的工作负载信息列表 :

　　DB2 pureScale 的工作负载均衡提供了不同粒度的分发方式，应用可以在连接级别 (Connection Level) 或事务级别 (Transaction Level) 来分发工作负载。

　　当使用连接级别的工作负载均衡的时候，应用发起新的数据库连接的时候，DB2 客户端会根据 DB2 pureScale 集群中成员节点的实际负载情况，将该数据库连接建立在集群中负载较低的节点之上。

　　在连接级别的工作负载均衡方式下，一旦连接被建立，则该连接会和某成员节点绑定，除非该成员节点发生故障，否则该连接上所有的事务也都会被提交到该节点上执行。从这里我们也可以看出连接级别的工作负载均衡可能对使用了数据库连接池等长连接技术的应用不太合适，因为这种情况下，连接往往在应用初始化的时候被建立并被放在连接池中，这样实际上每个连接在应用初始化的时候就被绑定到了相应的 DB2 pureScale 成员节点上，而此时的 DB2 pureScale 成员节点负载信息列表并不能真实的反应应用实际运行过程中的真实负载情况。

　　回页首

　　事务级别的工作负载均衡

　　在事务级别的工作负载均衡机制下，同一个连接中的不同事务，有可能根据节点的工作负载情况，被分布到不同的节点上去执行。

　　这里我们需要引入逻辑连接 (logical connection) 和物理连接 (physical transport) 的概念，所谓逻辑连接，指的是应用程序应用通过调用相应的 API 获取的一个数据库连接，例如，如下是在一个 Java 应用里面的一个逻辑连接：