我们考虑使用SVC的初衷有两个:1. SVC提供压缩2. SVC丰富的解决方案构建解决方案的生态圈您说的问题也是存在的,架构设计追求KISS原则,在解决一些问题时可能导致其他的问题,我们主要面向应用场景选择驱动因素最强的解决方
在oracle方面我们主要将 read/write的dbf 和write的redo,以及sequential write的arc在磁盘层进行隔离(使用不同的LUN),但PG方面没有独立的redo目前没有做特别的优化。GP、HANA等我们都没有使用。这是我们后续关注的重点,欢
嗯,我们引入新产品、新架构的必备功课。 1,投入产出(根据客户规模不同需要调整,我司规模较大现在比较容易体现规模效应,对于小规模的客户初期投入和TCO差距表现不太明显。 ---这个在13、14年我们就经历过,当时觉得差距不
是的,我们在这个问题上基于过去HDD的一些解决方案的经验,发现实际在OS core上主要是queue的设计和IO scheduling policy方面的影响较多。鉴于篇幅的问题,简单建议可以尝试在linux 7以前注意加大queue(这个是一定的),调度策
read方面,我们实际业务原来在存储read cache命中小于1ms,没有命中时最好的平均响应时间在6ms,主要集中在8ms段,一旦有高流量就会超过10ms。使用flash以后,系统随机读IO方面综合read response time在1ms左右。如果有大于128
我们也有相同的问题,现在没有找到较好的备份方案。当前的做法是:1.录音小文件:分层架构,从本地磁盘(多份)---中端存储---归档存储---磁带,周期设置中有重复多份数据,保护任何一个节点数据丢失用户数据不丢失。备份目前采用ndm
对这个问题的认识分为2个阶段:1. 在体验闪存的前2年,闪存几乎是不坏盘的,感觉这个维护真的轻松了很多;2. 从15~16年维护体验感觉,从平均每TB角度看闪存比HDD仍然故障率(年4%)低,但是随着我们盘子的增加,也出现过月更换率1.5%的
在块存储场景我们主要使用了IBM 的SVC+F900、HDS的G1000两种解决方案,考虑的主要出发点是产品的系统架构非常成熟有很久的历史,只是利用flash改善原有磁盘响应时间,同时具备硬件压缩能力维持性价比。IBM的F900收购TMS,是
1.Raid类型设计:我们在3.2TB以下采用Raid5,在3.2TB以上采用Raid6,对15TB flash 采用3D-Raid(3份校验);2. 我们roadming profile 需求20TB,采用metrocluter架构,一套存储完全故障时仍然能保障数万坐席人员访问的持续;3. 云备份
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30