Назад | Перейти на главную страницу

Amazon AWS Ephemeral диски и RAID1

К некоторым инстансам AWS прикреплены «эфемерные диски», которые намного быстрее, чем EBS. Но эфемерные диски будут пустыми и неинициализированными, когда ваш экземпляр будет остановлен и запущен. Однако данные на диске обычно сохраняются после перезагрузки экземпляра.

Вопрос: Следует ли мне использовать программный RAID1 на моем экземпляре AWS, созданный на основе временного диска и тома EBS?

Я думаю, что raid1 выйдет в деградированном режиме только с томом EBS, а затем мы можем использовать команды mdadm, чтобы добавить пустой эфемерный диск обратно в raid. Это позволит приложению запуститься на 5-10 минут раньше за счет снижения производительности при синхронизации raid1.

Задний план: У меня есть приложение, которое использует ~ 40 ГБ файлов данных. Время доступа напрямую зависит от производительности, поэтому чем быстрее диск, тем быстрее работает приложение.

Обычно мы запускали что-то от rc.local до данных rsync с диска EBS на временный диск, а затем запускали программное обеспечение. Синхронизация занимает 5-10 минут, что лучше, чем 5-20 минут, которые потребовались для синхронизации из другого экземпляра. Раньше мы даже использовали файлы данных с RAM-диска, который был не таким быстрым, как эфемерные диски.


Дополнительная информация - это i3.4xlarge, поэтому он имеет 2 временных диска NVME.

# hdparm -t /dev/md? /dev/nvme?n1 /dev/xvd?
/dev/md0:     9510 MB in  3.00 seconds = 3169.78 MB/sec RAID0 of two eph drives
/dev/nvme0n1: 4008 MB in  3.00 seconds = 1335.74 MB/sec Eph drive
/dev/nvme1n1: 4014 MB in  3.00 seconds = 1337.48 MB/sec Eph drive
/dev/xvda:     524 MB in  3.01 seconds = 174.17 MB/sec  gp2 16GB, 100 IOPs root
/dev/xvdf:     524 MB in  3.01 seconds = 174.23 MB/sec  gp2 120GB, 300 IOPs data
/dev/xvdz:     874 MB in  3.01 seconds = 290.68 MB/sec  gp2 500GB, 1500 IOPs raid-seed disk

Я создал raid1 с

mdadm  --create /dev/md1 --raid-devices=3 --verbose --level=1 /dev/nvme?n1 /dev/xvdz

который возвращает:

$ cat /proc/mdstat
Personalities : [raid0] [raid1]
md1 : active raid1 nvme1n1[4] nvme0n1[3] xvdz[2]
      524155904 blocks super 1.2 [3/3] [UUU]
      bitmap: 0/4 pages [0KB], 65536KB chunk

Любопытно, что рейд читает примерно так же быстро, как и более быстрые диски, и не ограничивается скоростью самого медленного диска.

/dev/md1:     4042 MB in  3.00 seconds = 1346.67 MB/sec
/dev/nvme0n1: 4104 MB in  3.00 seconds = 1367.62 MB/sec
/dev/nvme1n1: 4030 MB in  3.00 seconds = 1342.93 MB/sec
/dev/xvdz:     668 MB in  3.01 seconds = 222.26 MB/sec

Выключение / включение возвращает ухудшенный набор рейдов, но приложение все еще может работать, хотя и медленнее. Это позволяет избежать затрат на ожидание в течение 5–10 минут, и я могу повторно добавить эфемерные диски в рейд на лету без перезапуска приложения.

Итак, хотя кажется, что это работает отлично, есть ли что-то, что я пропустил или не учел?

Хм, я не уверен, что хочу смешать два такие разные тома в одном RAID1. Если вы сделаете это, половина ваших запросов будет обслуживаться более медленным EBS, а половина - более быстрым хранилищем экземпляров, что может привести к довольно непредсказуемой производительности. Я бы посмотрел на стандартные инструменты, чтобы добиться лучшей производительности.

смотреть на Предоставленный IOPS EBS диски (если вам нужен высокий уровень ввода-вывода с произвольным доступом) или EBS с оптимизацией пропускной способности (если вы последовательно читаете большие файлы). Они могут обеспечить необходимую вам производительность прямо из коробки. В цены здесь.

Вы также должны посмотреть на некоторые кеширование, тем более, что, как вы говорите, это в основном содержимое только для чтения. Каждый раз, когда файл нужен, вы можете посмотреть в директории локального кэша временного хранилища и, если он там, обслуживать его оттуда. Если нет, возьмите его с EBS и сохраните копию в кеше. Особенно, если все это только для чтения, это должен быть довольно простой слой кеширования.

Или если файлы на EBS являются файлами базы данных (что, как я подозреваю, может иметь место) кэшировать результаты ваших запросов или обработки в Memcache или Redis или в собственном кэше базы данных (например, Кэш запросов MySQL).

Надеюсь, это поможет :)

Я ... не стал бы использовать том RAID1, даже с --write-mostly. Снижение производительности при перестроении набора будет раздражать.

Что я бы рекомендую вместо этого изучить bcache. Я обнаружил, что это очень полезно в ситуациях, когда у меня есть доступ к твердотельным накопителям, но также есть очень большой объем данных для хранения (обычно очень большие базы данных PostgreSQL), для которых неэкономично покупать все SSD. Я использовал его только в «постоянном» режиме, когда он использует твердотельные накопители в качестве кеша с обратной записью, но у него есть режим, в котором уровень хранения кеша рассматривается как эфемерный, и никакие записи не считаются завершенными, пока они не на базовом постоянном хранилище.

40 ГБ достаточно мало для RAM-дисков, которые будут работать быстрее, чем рабочие диски. Как долго будет работать ваше приложение и стоит ли платить за экземпляр с увеличенным объемом памяти?

24x7 может быть слишком дорогостоящим. Но 40 ГБ в пределах досягаемости.

В качестве бонуса вам должно понравиться больше ядер.

Я согласен с кешированием запросов для детерминированных запросов, и любая буферизация со временем поможет.