Technical Blog Post
Abstract
本文介绍IBM i上的双活解决方案 - Db2 Mirror
Body
IBM i 在7.4版本中发布了新的产品Db2 Mirror。该产品提供给客户基于IBM i的双活的能力，能够极大程度的在保证数据完整度的前提下，大大缩短系统应对突发事件所带来的宕机时间。
Db2 Mirror提供本地数据中心的高可用的解决方案。该方案有如下特点：
1. 基于两台IBM i系统的高可用保护。在当前版本中，Db2 Mirror方案中的两个IBM i系统之间直连的距离不能超过100米，通过交换机，可以将该距离提高到200米。
2. 在双活条件下，用户可以对任何一台机器上的Db2 对象进行数据读写操作。
3. Db2 Mirror保存两份数据。通过高速的ROCE卡，Db2 Mirror可以保证这两份数据的完整性。在双活状态下，任意时刻的数据在两个节点上都是相同的。
4. 基于Db2 Mirror的上层应用，应对计划内或者计划外宕机时，可以在极短的时间内完成服务的切换。针对不同的应用架构，业务切换时间可以达到秒级甚至是趋近于零。
5. Db2 Mirror支持SYSBAS和IASP中的数据同步，并且同时支持外置存储和内置存储。在Db2 Mirror的初始化过程中，外置存储的效率会高很多。但是，在Db2 Mirror环境搭建完毕之后，数据的同步都是由操作系统来完成的，因此在双活环境中的数据同步并不依赖任何存储类型。
6. Db2 Mirror可以结合其他的数据复制软件（例如PowerHA for IBM i，或者MIMIX）来提供完备的HA/DR解决方案。
7. Db2 Mirror需要运行在IBM i 7.4及以上版本中，并且使用Power8及以上的系统。
1. 基于两台IBM i系统的高可用保护。在当前版本中，Db2 Mirror方案中的两个IBM i系统之间直连的距离不能超过100米，通过交换机，可以将该距离提高到200米。
2. 在双活条件下，用户可以对任何一台机器上的Db2 对象进行数据读写操作。
3. Db2 Mirror保存两份数据。通过高速的ROCE卡，Db2 Mirror可以保证这两份数据的完整性。在双活状态下，任意时刻的数据在两个节点上都是相同的。
4. 基于Db2 Mirror的上层应用，应对计划内或者计划外宕机时，可以在极短的时间内完成服务的切换。针对不同的应用架构，业务切换时间可以达到秒级甚至是趋近于零。
5. Db2 Mirror支持SYSBAS和IASP中的数据同步，并且同时支持外置存储和内置存储。在Db2 Mirror的初始化过程中，外置存储的效率会高很多。但是，在Db2 Mirror环境搭建完毕之后，数据的同步都是由操作系统来完成的，因此在双活环境中的数据同步并不依赖任何存储类型。
6. Db2 Mirror可以结合其他的数据复制软件（例如PowerHA for IBM i，或者MIMIX）来提供完备的HA/DR解决方案。
7. Db2 Mirror需要运行在IBM i 7.4及以上版本中，并且使用Power8及以上的系统。
Db2 Mirror的典型使用场景
1. IBM i Db2 作为数据库，应用运行在外围节点上。在该架构下，应用（例如Java客户端）运行在IBM i之外的系统上，通过不同的协议（例如JDBC）连接到Db2 for IBM i上。在这种场景下，应用端根据情况将负载分发到Db2 Mirror的两个节点上，并感知节点状态，以应对异常导致的切换。
1. IBM i Db2 作为数据库，应用运行在外围节点上。在该架构下，应用（例如Java客户端）运行在IBM i之外的系统上，通过不同的协议（例如JDBC）连接到Db2 for IBM i上。在这种场景下，应用端根据情况将负载分发到Db2 Mirror的两个节点上，并感知节点状态，以应对异常导致的切换。
2. Web应用或者服务和Db2数据库均运行在IBM i上。Web应用通过JDBC等方式连接到本地IBM i上的数据库。在IBM i的外围系统上，对Web应用的请求通过负载均衡器（可以是负载均衡软件或硬件）分发到Db2 Mirror的两个节点上。每个节点的应用访问各自节点的数据库，数据再通过Db2 Mirror的复制保证两台机器上的数据的完整性和一致性。
3. 运行在IBM i上传统的RPG，COBOL程序。对于该类型的应用，需要根据情况来进行相应的应用改造。如果用户想要达成双活的目标，需要保证原有的程序有能力在两个节点上同时处理业务。例如，很多银行的应用程序，往往是从Socket端口接收外部业务请求，从而在IBM i上进行处理。这样的应用在通常情况下需要进行一定量的改造。这样的改造需要保证应用从前端接收到请求以后，可以分别在两个节点上进行处理。
4. 将Db2 Mirror作为主备的HA架构。对于很多用户而言，应用改造有可能需要比较大的投入。在Db2 Mirror投产的过程中，用户可以选择多个阶段来完成最终双活的目标。第一阶段往往有很多用户选择从主备架构开始。这样的架构对用户应用改造的要求会变得相对较低，甚至对一些用户不需要应用的改造。即使使用主备架构，用户应用的切换时间也会大大降低，原因是Db2 Mirror在数据库层面是一直双活的，当应用切换的时候，数据库并不会因为切换而产生额外的切换时间，所以，时间损耗几乎全部都在应用端。更进一步，如果用户对应用稍作改造，比如通过应用预启动来缩短应用在切换过程中的启动时间等等，可以进一步减少切换时间。
5. 有一部分客户将Db2 Mirror的其中一个节点当作查询和数据分析平台。在以往的方案中，用户经常会通过FlashCopy或者逻辑复制的方式，将生产节点的数据复制到查询和数据分析节点，从而达到准实时的数据分析。所谓的准实时，说明数据分析所基于的数据是有延迟的。而用户使用了Db2 Mirror后，其中一个节点作为生产节点，另一个作为数据分析节点。数据分析节点拥有实时数据，并且其数据分析和查询操作并不会影响生产节点的业务运行。
Db2 Mirror的初始化
Db2 Mirror的初始化建立过程是通过对一个IBM i系统进行克隆来完成的。用户可以通过命令行或者图形界面将一台IBM i系统克隆并配置成一对Db2 Mirror的节点。对于IBM的存储，可以通过自动化的方式来完成克隆和初始配置。对于第三方厂商的存储，用户需要有一定的人工步骤介入。
Db2 Mirror的初始化建立过程是通过对一个IBM i系统进行克隆来完成的。用户可以通过命令行或者图形界面将一台IBM i系统克隆并配置成一对Db2 Mirror的节点。对于IBM的存储，可以通过自动化的方式来完成克隆和初始配置。对于第三方厂商的存储，用户需要有一定的人工步骤介入。
Db2 Mirror的初始化可以基于外置存储或者内置存储来完成。如果用户使用外置存储，则其初始化的效率会相对高很多。初始化过程可以通过暖克隆（Warm Clone）或者冷克隆（Cold Clone）来完成。冷克隆是指在系统克隆的过程中，源系统需要关机以后再进行克隆操作，以保证整个操作系统的数据都完成了落盘。而暖克隆无需对源系统关机即可开始Db2 Mirror的克隆与初始化操作。Db2 Mirror能够尽最大努力在暖克隆之前将数据从内存中刷入硬盘，尽可能的保证数据的完整性。
基于Db2 Mirror的架构方案
1. 一台Power系统上的两个IBM i逻辑分区之间搭建Db2 Mirror，并且两个逻辑分区共享一个IBM外置存储。在这种方案下，初始化克隆是通过存储的FlashCopy来完成。
2. 两台Power系统之间搭建Db2 Mirror，并且两台Power共享IBM外置存储。在这种方案下，初始化克隆是通过存储的FlashCopy来完成。
3. 两台Power系统之间搭建Db2 Mirror，并且这两台Power系统连接不同的外置存储。在这种方案下，初始化克隆是通过Remote Copy（例如Metro Mirror）来完成。
4. 两台Power系统之间搭建Db2 Mirror，同时通过PowerHA来完成远程灾备的搭建。在远程的灾备中心，两台灾备系统之间在数据中心切换后也可以搭建Db2 Mirror。
5. 两台Power系统之间搭建Db2 Mirror，同时通过逻辑复制技术来完成远程灾备的搭建。对于逻辑复制技术，远程灾备中心可以选择一台IBM i或者两台IBM i进行灾备保护。
Db2 Mirror的管理
Db2 Mirror提供命令行和图形界面两种管理接口。对于命令行，用户需要使用SQL Service来对Db2 Mirror进行操作。Db2 Mirror的图形界面提供了更完善的功能，并且在基础管理功能之上，还增加了额外的增强管理功能，所以建议用户使用图形界面。
通过Db2 Mirror中的任意一个节点都可以进行管理工作。用户甚至可以选择通过第三方节点来对Db2 Mirror环境进行管理。图形界面支持通过一个IBM i系统对多个Db2 Mirror环境进行管理，方便用户在多机环境下进行双活运维工作。
Db2 Mirror的性能预期
不同的数据操作对于Db2 Mirror的性能是有不同影响的。对于写和更新操作，系统需要保证数据在两个节点上的一致性，所以写和更新的IO操作会需要耗费比单机更长的时间。对于大多数读操作而言，性能预期会跟单机相比差不多，甚至在某些情况下由于充分利用了两台系统的CPU，读操作的性能还会在单机基础上有所提升。
不同的数据操作对于Db2 Mirror的性能是有不同影响的。对于写和更新操作，系统需要保证数据在两个节点上的一致性，所以写和更新的IO操作会需要耗费比单机更长的时间。对于大多数读操作而言，性能预期会跟单机相比差不多，甚至在某些情况下由于充分利用了两台系统的CPU，读操作的性能还会在单机基础上有所提升。
对于用户的应用而言，去衡量单一IO的性能意义不大。不同种类的应用，在Db2 Mirror环境中的表现也不一样，能够调整的空间也不一样。例如，对于在线交易类型的应用，很多情况下其读操作会有一定的占比，因此，这样的交易在Db2 Mirror的环境中的总体性能相对于批处理类型的作业（写入和更新操作占比较大）的表现要好很多。同时，用户的应用在Db2 Mirror环境中有比较多的调整空间和手段，无论是对系统的配置的改动，还是对应用程序的改动，都会有助于总体性能的提升。对于用户而言，在做Db2 Mirror的可行性分析中，需要有对性能测试，配置改动以及应用改动的预期。
总结
Db2 Mirror提供了基于IBM i的双活解决方案，该方案能够大幅度提高用户的业务连续性目标。在保证RPO的情况下，RTO也能同时达到相对理想的状态。通过对Db2 Mirror的实施，用户的高可用等级可以得到提升。
Db2 Mirror提供了基于IBM i的双活解决方案，该方案能够大幅度提高用户的业务连续性目标。在保证RPO的情况下，RTO也能同时达到相对理想的状态。通过对Db2 Mirror的实施，用户的高可用等级可以得到提升。
关于作者：王云是IBM i上的资深架构师，他所负责的领域涵盖IBM i上的高可用性，云计算，系统管理等等。
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]
UID
ibm11144912