3同行回答
回复 1# szhangkang
其实，应用级容灾和数据级容灾没有本质的区别。解决方案和数据级的也基本一致。
想想，应用级容灾比数据级容灾多了什么？ 无非就是除了存储数据以外，还需要应用可用。
那么我们的数据级容灾一般怎么做的？ 存储复制，数据库复制，CDP，甚至LVM镜像。
在灾备站点，数据已经存放在存储上了。 在很多实施案例里面，基本都配备了提供这些数据被访问的数据库服务器（基于数据库复制的就更不用说了）。 那么，在这个基础上，我们要解决的就是把应用搭起来，让灾备站点的应用可以连接到灾备站点的数据库，实现对应用对外提供服务。
那么难点在哪里呢？ 难点在客户的环境和应用上面。
第一，用户的应用上的IP地址问题。 很多应用往往将数据库连接的IP地址或者与其它业务系统对接的IP地址，写死在程序里面或者配置文件里面，而灾备站点的IP地址一般与生产站点不一致，所以，当应用部署到灾备站点的时候，需要修改这些IP地址。但是，从应用中清理这些就很费功夫，或许有的应用甚至连源代码都没有，要清理这个就更难以下手。
或许有的客户生产站点和灾备站点的IP地址是完全相同的，这个就不存在这个问题。但是这种网络地址结构灵活性不够，对于应用的双活支持就不太理想。
第二，应用的配置问题。 多数应用将应用代码和应用环境配置没有分离，导致应用不能灵活的部署，换一个环境，就要修改一次应用。 由于没有独立的配置文件，在生产站点应用更新后，不能直接将生产站点复制过来应用投入使用，必须进行修改。这也加大了应用灾备的实施的难度。 如果设计良好的应用，应该是程序和配置分离的。当日常应用维护和更新的时候，同步的只是程序，而配置则各个站点保持独立。这样，只需要在建立应用灾备的时候根据灾备站点的环境修改好配置，平时应用更新依赖自动(例如使用 crontab + rsync/scp)或者手动同步即可。
第三，对于访问应用的问题，同样，因为很多环境中，用户在访问应用的时，也是基于IP地址的，那么在切换的时候，需要用户修改访问的目标IP地址，这对于有大规模用户的应用系统来讲也是一件麻烦的事情。因此，如果能将用户的访问改为基于DNS的方式，那么在中心端通过修改DNS即可实现应用系统访问的切换。收起
其实，应用级容灾和数据级容灾没有本质的区别。解决方案和数据级的也基本一致。
想想，应用级容灾比数据级容灾多了什么？ 无非就是除了存储数据以外，还需要应用可用。
那么我们的数据级容灾一般怎么做的？ 存储复制，数据库复制，CDP，甚至LVM镜像。
在灾备站点，数据已经存放在存储上了。 在很多实施案例里面，基本都配备了提供这些数据被访问的数据库服务器（基于数据库复制的就更不用说了）。 那么，在这个基础上，我们要解决的就是把应用搭起来，让灾备站点的应用可以连接到灾备站点的数据库，实现对应用对外提供服务。
那么难点在哪里呢？ 难点在客户的环境和应用上面。
第一，用户的应用上的IP地址问题。 很多应用往往将数据库连接的IP地址或者与其它业务系统对接的IP地址，写死在程序里面或者配置文件里面，而灾备站点的IP地址一般与生产站点不一致，所以，当应用部署到灾备站点的时候，需要修改这些IP地址。但是，从应用中清理这些就很费功夫，或许有的应用甚至连源代码都没有，要清理这个就更难以下手。
或许有的客户生产站点和灾备站点的IP地址是完全相同的，这个就不存在这个问题。但是这种网络地址结构灵活性不够，对于应用的双活支持就不太理想。
第二，应用的配置问题。 多数应用将应用代码和应用环境配置没有分离，导致应用不能灵活的部署，换一个环境，就要修改一次应用。 由于没有独立的配置文件，在生产站点应用更新后，不能直接将生产站点复制过来应用投入使用，必须进行修改。这也加大了应用灾备的实施的难度。 如果设计良好的应用，应该是程序和配置分离的。当日常应用维护和更新的时候，同步的只是程序，而配置则各个站点保持独立。这样，只需要在建立应用灾备的时候根据灾备站点的环境修改好配置，平时应用更新依赖自动(例如使用 crontab + rsync/scp)或者手动同步即可。
第三，对于访问应用的问题，同样，因为很多环境中，用户在访问应用的时，也是基于IP地址的，那么在切换的时候，需要用户修改访问的目标IP地址，这对于有大规模用户的应用系统来讲也是一件麻烦的事情。因此，如果能将用户的访问改为基于DNS的方式，那么在中心端通过修改DNS即可实现应用系统访问的切换。收起
浏览2242