建议使用标准的S3接口的SDK,这样做开发成本和运维成本都较低
1,我司的命名规范是和应用编码保持一致;2,理论上只要对象存储平台开放api接口,数据治理平台可以对接api就可以实现对接工作。
首先可以针对bucket设置容量,限制每个bucket的大小;其次可以设置流控,也是就说限制每个bucket单位时间内允许读写的速率,从而实现资源隔离。
分布式存储的未来是否美好,我觉得取决于以下几点,一是分布式存储能否替代集中式存储目前使用的场景?这里包括性能的替代性和稳定性的替代性。二是分布式存储替换集中式存储的方案是否能够做到平滑,即用户需要付出的成本较
有两种方案可供选择,一种是使用每个厂商自己的容灾方案,这样不容易扯皮;另外一种是使用能够兼容两个品牌的第三方解决方案,这就需要梳理好需求,界定清楚界限和责任范围。
建议使用超融合厂商提供的灾备方案,并结合自身需求。在笔者看来,超融合的灾备方案和现有的容灾方案并没有本质的区别。
不建议使用这么多种类的超融合品牌,说句实话,这真的是给自己挖坑。对于已经是这样的情况,只能寻找能支持以上品牌的第三方灾备工具了。
一般建议使用超融合厂商自己的灾备方案,这样兼容性更好,而且不容易出现扯皮。
分布式存储和集中式存储的分配权重并没有一个官方的或者民间的建议,这完全取决于每个公司自身的业务场景和存量资源的使用情况。两者对于大多数企业而言并没有什么明显的区别,更多的是在管理层面、安全层面、容灾层面有
超融合就是实现iaas的路径而已,和上面跑什么样的业务关系并不大,除非对oracle的性能有特别高的要求,不然目前的业务场景都是可以运行在超融合平台上的。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30