На m3.xlarge пример (Оптимизирован для EBS - Правда) :
Есть два диска EBS: / mnt / data0, / mnt / data1
Одиночный дд:
dd bs=1M count=1024 if=/dev/zero of=/mnt/data0/test conv=fdatasync
1024 + 0 записей из 1024 + 0 записей из 1073741824 байтов (1,1 ГБ) скопировано, 15,9016 с, 67,5 МБ / с
Два параллельных dd:
1073741824 байта (1,1 ГБ) скопировано, 29,2529 с, 36,7 МБ / с
1073741824 байта (1,1 ГБ) скопировано, 33,8585 с, 31,7 МБ / с
Очевидно, что общая пропускная способность EBS является узким местом. Ожидается?
Если общая пропускная способность EBS ограничена независимо от количества томов, какой смысл в чередовании EBS?
Похоже, между экземпляром и облаком EBS существует единое сетевое соединение. Пропускная способность описана здесь: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
Итак, ответ таков: если не будет достигнут предел числа операций ввода-вывода в секунду, добавление дополнительных дисков EBS не улучшит общую производительность EBS экземпляра.
Для меня главное преимущество наличия нескольких томов EBS меньшего размера, а не одного большого - это управление затратами.
В качестве примера прямо сейчас на нашем сервере DEV у нас есть 3 тома EBS по 100 ГБ, подключенные к ZFS (настроенные в raidz1 но это потому, что я параноик по поводу потери данных).
Разработчики продолжают говорить мне, что нам потребуется более 1 ТБ дискового пространства, но пока оно нам не понадобится, мне не нужно его выделять. Это позволяет снизить наши затраты.