技术开发 频道

实现可用性跨越DB2 pureScale高可用性

    【IT168 技术文章】

    横向扩展架构的作用并不仅为了处理能力的增加。采用这种架构设 计的系统在遇到组件故障时可以继续处理事务,从而能够交付更高的可用性。

    与分布式平台上的其他产品相比,DB2 pureScale将可用性提升到 了一个新的高度。DB2 pureScale允许访问所有不需要恢复的数 据分页,并且随时可以洞察哪些分页需要恢复,而不需要执行任何 I/O操作。这是通过集中化CF的独特功能实现的另一项重要创新。

    每当成员将一个页读取到它的缓冲池中时,CF都会感知到这一事件并 持续对其进行跟踪。任何时候当成员希望更新一页中的行,CF同样能 够知晓相关事件。当一个应用执行事务时,成员会将脏页直接写入到CF的内存中。此流程允许集群中希望读取这些经过更改的页的任何 其他成员直接从CF获取更新。更加重要的是,从恢复的角度来说,如果任何成员出现故障,CF中会保留该失败成员正在处理更新的页列表,同时还有一些页已经完成更新和提交,但尚未写入磁盘。

    任何关系数据库管理系统(RDBMS)的恢复流程首先都需要重新执行任何已提交的事务,以确保磁盘上这些事务的页是最新的(此流 程称作redo恢复)。此外,任何数据库服务器都需要撤销任何未完成的事务,即在故障之前对磁盘数据执行了更改但尚未提交(此流 程称作undo恢复)。

    在共享磁盘集群中,非常关键的一点是要确保集群中的其他节点没有读取或更新尚未恢复的磁盘中的任何分页(恢复这些分页之后才 可以对这些行执行新的事务)。这正是CF的闪光之处: 由于CF知道 哪些页正处于故障节点的更新过程之中,并且CF已经将该节点提交的脏页保存在它的集中缓冲池中,因此DB2 pureScale在确定哪些 分页需要恢复时不必阻塞其他成员持续处理事务。其他架构则需要了解哪些节点占用的处理时间较多,以便根据锁信息的分布来确定哪些节点必须恢复。

    从较高的层面来看,可以很容易地解释DB2 pureScale环境中的这种恢复进程。每个成员都有空闲的进程,但它们都随时准备着处理故障事件。如果某个成员出现故障时,其中一个恢复进程便会激活; 既然这些进程已经存在,因此操作系统不必浪费宝贵的系统时间来创建进程,为它分配内存等。此恢复进程会立即将CF中的脏页预取到它自己的本地缓冲池中。大部分恢复过程都不需要I / O 操作,因为需要恢复的页已经在C F的集中缓冲池中了。此外,页预取机制使用轻量级的R D M A在C F与恢复成员之间实现迅速有效的传输。在这段时间内,所有其他成员上的所有其他应用将继续处理请求。如果它们需要从不需要恢复的任何页获取任何数据,那么它们可以继续执行自己事务。因此,它们可以继续从磁盘读取页,因为CF已经知道磁盘上的哪些页是干净的,以及哪些页需要恢复。然后,恢复进程读取故障成员的日志文件,以便于重放必要的事务来重做或撤销故障成员所做的更新。

    对于典型的事务工作负载来说,从成员出现故障到故障节点未更新 完的分页可供其他事务使用的时间间隔通常在20秒以内。注意,这同时还包括故障检测时间,而某些供应商在提到恢复时间时都排除 了这一时间。数据库中的所有其他分页无时不刻(甚至在成员出现故 障之后)都是完全可用的。

    此外,系统中像PowerHA pureScale集群加速器这样的组件是冗余的。DB2 pureScale支持双重CF功能,这样锁和共享缓存信息就可以存储在两个相互独立的位置,以应对主CF出现故障的情况。
 

0
相关文章