主要看数据的持久层部署在对象存储或者集中存储上，可以分别采用上述的持久层方案进行部署。而对于应用的业务连续性，则需要考虑后端微服务架构的应用提供方式进行选择，目前常见的都是通过容器化部署来实现，通过容器管理平台实现应用的高可用，例如VMware Tanzu提供的高可用保障...

答案是肯定的，多种方案的叠加肯定能够防范更广泛的灾难风险。但是需要注意的是，在做DRP预案的时候，针对不同的灾难场景要有详细的预案，要充分分析不同灾备解决方案的灾难恢复效果和适用场景。...

不只是中间件，应用程序连接数据库更改为容灾数据库连接可以有以下几种办法：1、二层通的业务系统，可以直接切换数据库对于应用的服务IP地址即可。2、三层的业务系统，可以使用DNS域名访问，应用程序无需变动。3、如果不适用DNS，可以在应用系统里面配置hosts文件替换任务，将数据库的...

个人理解是，自动化切换的工具平台需要与数据中心灾备管理工作深度集成，并不是简单使用一套工具就能实现的。灾备自动化切换的工具平台大致需要满足三大的功能点：1.自动化能力，包括集成现有类似ansible这种的自动化工具，在不同运行环境执行切换命令和脚本  2.流程编排能力，灾...

1、灾备系统中DNS的设计需要注意点有那些？DNS高可用性：在灾备系统中，DNS的高可用性非常重要。如果DNS出现故障，将导致整个灾备系统无法正常工作。因此，建议使用多个DNS服务器来提高系统的可用性，并在负载均衡设备中配置合适的策略，确保每个请求都能够得到响应。DNS解析的正确性：...

容灾无外乎于两类，应用系统、缓存、数据库系统，当然容灾也要考虑高可用，但是允许有中断时间的，具体看SLA.（1）应用系统大都无状态， 主要保证每次版本更新的时候在主系统和灾备系统上同时发版；（2）数据库系统： 大都是以传日志的方式，保证灾备数据库和主数据库尽量同步。   由于是客...

这个是不同的级别的问题，数据库双活保证的业务的持续性，但是灾难的发生往往是突然的，虽然说双活的情况下这个概率会比较低，但是还是需要防范于未然所以，即使数据库是双活，灾备也是必须的。...

灾备如果不是双活的话，我们手工切，自动切的你还是检查状态，我们采用的客户端采用访问列表，地址从上到下自动去连，1不通连2,2不通连3。。。主备之间做好配置，或者做个小脚本，一年做个两次演练保障切换质量...

这个话题很大，说起来不是简单的就说清楚的规划本身就不是一个人简单拍脑袋完成，需要建设单位的相关部门一起根据当下现状和未来的发展需要，综合在做出来的.至于同城，双活，异地什么的，还是根据用户实际IT现状来说话，没有调研就没有发言权。本来灾备建设就是不是一个简单的IT集成...

你说的这些确实是目前灾备中心的现状。灾备资源目前大多还是空闲为主，一部分用户拿这部分资源临时做测试环境至于每天数据里和带宽，1 根据实际业务量情况来说的。2 跟你的选择的技术产品也有关系...