之前遇到过类似情况,提几个想法:一是要数据库做优化,再增加投入,具体来说就是数据库数据要分散在多个大小接近的表空间,物理磁带库使用多个磁带机去并发备份,存储光纤通道带宽也要够,理论上最大备份速度可以接近数据库磁盘读
深度使用过TSM和CV,试用过NBU,个人感觉CV的功能迭代能力更强,产品也容易上手,能较容易对接多种备份介质,实现多种类型数据的备份,数据重删压缩,容灾方案,可视化管理等都较出色
做过一些国产超融合的自研虚拟化的功能测试,单看虚拟机在线迁移这一项虚拟化基础功能,很多产品都测出来一些瑕疵。
个人观点是:超融合很适合作为一种过渡方案,轻量级,投入少。但在应用已经容器化改造的情况下,保留超融合的必要性很低,反而增加方案复杂度,而基于裸金属的容器云才是更合理的选择。
一方面,信创项目落地可从两条主线展开,信创云主要对应的是信创基础硬件+操作系统的集成解决方案,应用信创适配对应的是信创操作系统+其他软件的集成解决方案,着重抓这两条主线,选择落地经验更丰富、案例更多的厂商,可以显著
个人观点供参考,这个问题不能仅仅从数据库这个技术点去考虑,还要结合自主可控的技术生态体系一起去做判断:1.所选用的数据库产品自身是否自主可控:是否是完全独立知识产权,技术上完全可控,这种自然是无异议的;但是自主可控不
首先需要明确的是两地三中心架构下,异地容灾主要针对的是区域性的灾难,异地的物理距离要合理;其次是异地容灾的目标,不同灾难恢复等级对于着不同的成本、收益;另外是技术方案上,异地间的距离限制了数据中心间的数据交互,网络
波分设备故障的情况下,只能保主中心运行,结合自身的同城容灾技术架构,评估是否需要采取切断同城数据中心网络入口、数据中心间互联、数据复制链路以及同城中心部署的应用系统等等措施。待故障恢复后,再启用双中心。
数据库跨中心双活方案:以跨中心的存储双活技术为基础,将数据库本地双活扩展到跨中心双活;该方案对数据同步链路要求较高,对各种故障较为敏感,需要数据库端、操作系统以及底层存储的共同配合调优,以应对业务中断和数据一致性
SAN 存储:包括存储主备复制和存储双活技术。存储主备复制方案对主存储影响较小,对数据复制传输链路要求不高,但容灾切换过程较为复杂,容灾切换时间较长;存储双活方案的容灾切换时间在秒级,应用无感知,但对数据同步的链路要求
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30