db2数据库如何实现应用级双活
我们现在的情况大概是这样：核心使用的db2，同城与异地已经实现了数据级灾备。现在主要是想实现应用级双活，如何保证前期的投资，提高系统的健壮性，又能把灾备中心的资源利用起来。
2同行回答
个人见解哈。
第一个关键问题：db2是HA架构还是Purescale架构，能否改成purescale架构。假设能够改成purescale架构，那么数据库这层的双活问题可以基本解决。
第二个关键问题：存储是什么设备，什么架构。存储最起码可以实现双中心的HA或者AA架构才能支撑上层数据库的双活。可以考虑一些存储虚拟化网关设备加入到存储架构当中，例如SVC、VPLEX、MCC都能实现。但是一定要考虑到与现有存储的兼容性和扩展性问题。
第三个关键问题：同城双中心要实现光线互联，根据存储特点决定SAN环境是否需要打通，打通之后，SAN环境的逻辑隔离也非常重要。
第四个关键问题：同城双中心之间要实现大二层，至于说负载均衡要不要实现跨数据中心集群完全基于自己的环境特点来决定，小集群组合和大集群各有利弊。
在这个过程中原来的设备不会丢弃，只需要增加新的设备，修改现有配置就可以。但是里面会伴随非常多的变更和迁移，最重要的包括存储虚拟化变更、数据库架构改造、网络环境扩展等。具体实施建议一步一步来，系统可以从外围系统开始。
收起- 现在主要是ha,,不过同城已是大二层，主备中心数据实时同步，使用vplex metro，底层已经具备双活条件
- 那接下来考虑的问题就是数据库层是跨数据中心的HA还是转向AA。 应用层结合应用负载的数据引流问题，也就是说从客户端到数据中心的故障感知及数据流切换的问题了。
看你要实现应用级双活的程度了
仅仅应用服务器的双活，那很简单，DNS引流+应用负载就能实现，灾备的应用服务器访问的是生产的数据库。
数据库双活，又分非对称型双活和对称型双活，非对称的一般是生产写、灾备读，可通过数据库复制技术实现，像你是用DB2，完全可以用DB2 HADR实现灾备的读功能，加上上面的应用服务器的双活，可以满足你的“保证前期的投资，提高系统的健壮性，又能把灾备中心的资源利用起来”的要求。但要注意DNS引流的策略设计、应用的读写分离逻辑设计，由于DB2 HADR是网络复制，由于是核心，要注意同步的带宽和速率和效率问题。对称型双活，像DB2只能用DB2 GDPC技术了，需要核心DB2进行改造，停机窗口很长，除非用迁移的方式，否则风险太大。而且需要专门的ROCE卡或者INFINIBAND卡或者万兆，网络也需要改造，综合来说，在核心上不建议使用这种动作太大的方式。（实在要用，可以考虑用迁移的方式，备份恢复、前滚，从原核心迁移到新搭建的DB2 GDPC中）
上面的DB2双活，存储也是双活，存储是基于GPFS网络方式的同步实现双活的，为了更加稳固可靠，也可以考虑DB2 GDPC+双活存储（存储网关的双活或者高端存储的双活）实现。但难度和改造很大，就看魄力和决心了。
- 我们现在都是ip地址，同城已是大二层，核心区引入dns的目的是什么？
- 请求发到生产机房的核心DNS，DNS起到请求负载均衡和分流的目的，分发至两个机房的应用负载或者应用服务器上。相比直接用应用负载分发请求至两个机房的应用服务器，效率更高。
- [此评论已删除]
- 非必须，要考虑请求的数量和流量以及应用集群的规模。刚才提的只是DNS的域名解析和分流功能，有些专用的DNS还能起到应用负载的功能，能够对应用进行健康检查，和权重分配，会话保持等。通常DNS+应用负载是互联网等业务的标配，因为可以从广域网就将流量分流至两个中心，减少两个中心间的大二层流量。内网当然也可以采用这种架构。