云服务器磁盘IO问题的思考
之前云服务器的磁盘IO性能比同配置的物理机弱，提工单问了下售后工单支持，售后工单支持说“因为阿里云ECS做了三重数据备份保护，所以磁盘性能较普通物理机磁盘有性能下降”，其实这种
为了保证数据安全性，底层分布式存储是强制多份写入，并且多份数据强制分布在多个交换机下, 追求数据安全性，带来的是性能的开销的方式，我能够理解，毕竟做云计算服务提供商，是不能给用户丢数据的，数据丢了谈什么数据安全性和可靠性，不过这种为了追求数据安全性第一的精神我真得夸下阿里云，不但给用户提供了三重备份，还控制台提供了自动快照和系统快照功能，唯恐我们把数据丢了。我也相信阿里云能否把磁盘IO问题解决掉，在保证安全性的基础上提升掉磁盘io问题，据说他们正在做SSD高性能磁盘，要是产品开发完成，将是国内第一家提供SSD高性能磁盘的厂商。
我也买过Ucloud的云服务器，在说下Ucloud声称的高性能磁盘，其实也就是本地磁盘，什么叫本地磁盘，就是数据没有备份丢了就丢了，追求磁盘IO速度而没有保证数据安全性，忽悠了不少用户过去。Ucloud的云磁盘测试开始的时候是不错的，随着压力增大，读写iops下降的很厉害，比阿里云还差。有用过的可以说下，咱们大家一起讨论下。
既然是ECS技术深水区，大家提点深度的建议和讨论吧。
写回答
-
-
-
-
-
-
-
-
-
Re云服务器磁盘IO问题的思考没办法同意你的观点。
写三份就要慢一点这不专业，磁盘阵列都可以做到写多份速度还快。
一份写成功完全可以返回，其它写没写成功是备份系统内部的问题。不应该将内部影响扩散到外部。
只能说阿里现在暂时没有很好的实现这个功能而已。并不是写三份这个功能理论上必定要比写一份慢。速度应该是跟设备数量有关的，如果3分数据写入到3个物理设备，那理论上最快的那份写好就可以算完成。
如果3份数据写到6个物理设备上，每个设备只需要写1/2。理论上只要略多于一半的时间就可以完成。2014-11-05 11:23:18赞同 展开评论 打赏 -
oracle数据库技术支持服务 www.yundba.com 云库管Re云服务器磁盘IO问题的思考
http://bbs.aliyun.com/read/180238.html?spm=5176.7189909.0.0.bdI9if
一个美好的设计
国内数据库io特点基本上属于白天忙、晚上闲； 原因： IT的功能: 总结6个字：记录、控制、统计 , 系统忙闲规律必然符合人类的活动规律； 云ORACLE评估测试：性能优化/故障排除/长期代维 业务联系QQ：123614791 如果云上运转是服务于国内业务的数据库，那还会势必造成白天业务高峰时io的争用，晚上巨闲。 实际上，服务于美国业务的数据库（如敦煌网）正好和上面的情况相反！ 云ORACLE评估测试：性能优化/故障排除/长期代维 业务联系QQ：123614791 如果能 把服务于中国业务的数据库和服务于 美国业务的数据库 配比（1:1） 放在云平台当中，可用的IO带宽就提高一倍 。 阿里已在美国上市，靠其影响力， 实现这个并不难。 云ORACLE评估测试：性能优化/故障排除/长期代维 业务联系QQ：1236147912014-10-27 14:33:51赞同 展开评论 打赏 -
-
-
-
回4楼appayud1v的帖子redis内存数据库dump应该是大块io写吧，平均io块大小及吞吐量有多少？如果当前的磁盘性能不足，可考虑用4块磁盘做raid0来聚合性能。
-------------------------
回3楼overlook的帖子写一份成功就返回，对时延有一定的帮助，但是可靠性大打折扣。
在第一份数据返回成功后、第二份数据备份完全前，如果第一份数据所在的设备crash掉了，业务就中断了。像阿里云这么大规模的云计算场景，出现这类异常还是很容易的，毕竟硬件有一定的故障率，很难避免。-------------------------
回楼主at6569s2r的帖子ucloud采用本地存储的方案，在该方案中有两层存储，第一层是基于内存的cache，第二层是SATA存储，通过后台任务将cache中的数据刷到SATA盘中；ucloud性能高是指纯写（100%）的场景，能将所有的写io落在cache中，从而达到性能不错的效果；这种方案有致命的缺陷 ：
1.数据可靠性：当cache中有未刷到SATA盘的脏数据时，出现机器crash，数据必丢失；一般的x86硬件（包括整机及机械硬盘）都存在0.02%的故障率，这种本地存储+cache提升性能的存储方案一定会出现宕机数据丢失的情况。
2.运维管理成本高：单台物理机的cache毕竟有限，它不可能将vm所有的写io数据都能存在cache中，一旦有io未落cache而落SATA盘，性能将出现数量级的下降；如果是客户关键业务遇到这种情况，将不可接受；要解决这个问题，只能是迁移vm及数据；由于是本地存储，迁移vm必然要迁移数据，此时又会消耗大量的物理机网络带宽及cpu资源，进而影响其他的vm运行且迁移时长不可控；同时，这种迁移必然是手工的，难于做到自动化，运维管理成本高可想而知；
3.场景非常有限：1）对于只读io场景，特别是随机读io，由于cache难于做到随机读命中，此方案中的cache对读io就失效，性能就回归SATA盘的能力；2）对于随机读写混合场景，由于读做不到cache命中，读时延上升导致写时延也上升，结果是cache失效。在实际应用环境下，100%的写io场景是相对较少的，大部分还是读写混合场景。-------------------------
回9楼overlook的帖子io策略可配置的方式对用户技术水平要求较高。相比传统IT，云计算一大好处是将用户从IT运维管理中解放出来从而聚焦自己的业务；io策略可配置可能对少数高手来说有定制化的手段，但对大部分不那么高手的用户来说可能会带来麻烦。从云计算平台来看，这种方式会带来额外的异常处理及运维管理成本。-------------------------
回10楼stonys的帖子你现在的业务需要怎样的性能？比如需要多少IOPS、多少BPS等2014-09-25 21:51:09赞同 展开评论 打赏 -
我们大部分服务器基本不用磁盘，都是内存数据库
但是每次copy，备份，都是难受死人，太慢了
要求不高，只要能让我随时加载一些没有备份的临时磁盘即可，或者全换ssd
顺带一提，redis这个内存数据库因为磁盘io，每次dump和aof flush也是性能贼低，这个没办法只能这样了2014-09-25 19:27:50赞同 展开评论 打赏 -
Re云服务器磁盘IO问题的思考可以做成delay backup，先把数据写到一个节点，然后返回写入成功。这个节点在把数据备份到其他节点上。
-------------------------
回6楼storforward的帖子写一块磁盘就返回的可靠性等同于单机使用本地磁盘，对于大多数web服务已经足够用了，更别提mongodb为了io速度的写到内存就认账的cluster write策略。
应该把IO的策略改成可配置的，交易数据用三磁盘策略，其他丢了也没关系的用快速策略2014-09-25 19:15:10赞同 展开评论 打赏 -
-
Re云服务器磁盘IO问题的思考感觉讨论下来，有点变成一个矛和盾的问题；
其实数据安全性和可用性（包括稳定性）是我们最关注的问题2014-09-25 11:39:10赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
