在m3.xlarge实例 (EBS 优化- 真的) :
有两个EBS磁盘:/mnt/data0,/mnt/data1
單身 dd:
dd bs=1M count=1024 if=/dev/zero of=/mnt/data0/test conv=fdatasync
1024+0 条记录输入 1024+0 条记录输出 1073741824 字节(1.1 GB)复制,耗时 15.9016 秒,67.5 MB/秒
两个并行的 dd:
已复制 1073741824 字节(1.1 GB),耗时 29.2529 秒,36.7 MB/秒
已复制 1073741824 字节(1.1 GB),耗时 33.8585 秒,31.7 MB/秒
显然,整体 EBS 吞吐量是瓶颈。这是预料之中的吗?
如果无论卷数量多少,EBS 总吞吐量都是有限的,那么 EBS 条带化的意义何在?
答案1
看起来实例和 EBS 云之间只有一条网络链路。吞吐量描述如下:http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
所以答案是,除非达到 IOPS 限制,否则添加更多 EBS 磁盘不会提高实例的整体 EBS 性能。
答案2
对我来说,拥有多个较小的 EBS 卷而不是一个大型 EBS 卷的主要好处是成本管理。
举个例子,现在在我们的 DEV 服务器上,我们有 3 x 100 GB 的 EBS 卷附加了 ZFS(已配置,raidz1
但那是因为我担心数据丢失)。
开发人员一直告诉我,我们需要 1 TB 以上的空间,但在我们需要之前,我不必配置它。这样可以尽可能降低我们的成本。