理解您的需求是从易用性和可管理性的角度来看切换的解决方案。VM Recovery Manager是个挺好的选择,相对与传统的监控和管理方式,它增加了VM失效检测、跨站点的定制化脚本切换、应用监控和设置多种迁移策略的功能,而且
存储复制过程中链路的抖动不会丢数据,抖动结束后数据会追齐!
这问题比较宏观,同城双活概况上来讲要考虑的层次有: - 网络层 - 应用层 - 数据库层 - 存储层这几层的实现难度是不同的,通常网络层和应用层比较容易实现,成熟的产品和方案也比较多,因为这两层只分发请求,不处理请求,比较容
您谈到了双活 同时 还有业务切换,那么我理解还是主备的模式,不然完全的双活系统就不存在切换的问题。核心业务切换,前提一定是业务的分级和分组之后的切换,不然只是某个业务切换了,其他的相关业务还留在原中心,这样的切换
数据中心的双活,不同的客户有不同的理解,通常的理解是指两个数据中心均处于运行状态,可以同时承担一定的业务能力。但根据备中心能够承载的业务能力来区分,又可以分为以下几种: 主备模式:即生产中心完全承载主生产任务,备中
您这个问题有点儿大,我尝试从我的角度来回答一下。目前看到的同城双活的用户,很多是指同城双中心都可以提供服务,但针对于某一个具体业务而言,并非是双中心都数据库均衡负载提供服务。可能一边提供服务,另一边数据级同步复
您说的非常对,光速有限。完全的读写双活一体,是应用双活+数据库双活+数据存储双活,目前影响这种架构实现的比较大的困难就是数据库双活和数据存储双活。距离过远,即使线路稳定,也会有较大的延时,就会对数据库的双活造成影响
80-100公里,基本已经超出了各家存储同城同步复制的极限了,除非线路质量非常佳,不建议做存储的同步复制了。可以考虑异步的复制方式
核心系统存储的跨中心复制,通常是中高端存储都会包含的功能。我理解问题中的复制模式,是指同步或异步。 根据客户两中心间的线路质量情况、线路带宽情况以及想实现的RTO、RPO不同,来决定是同步还是异步。在各厂商存储的
双活是一个建设目标,但从城商行用户的实现角度来看,并不是一步到位的。平衡点一方面是建设和维护成本与希望达到的RTO和RPO间的平衡,另一方面是技术复杂性带来的衍生不确定性增多和人为可控之间的平衡。目前看,双中心实现
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30