К некоторым инстансам 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 ГБ в пределах досягаемости.
В качестве бонуса вам должно понравиться больше ядер.
Я согласен с кешированием запросов для детерминированных запросов, и любая буферизация со временем поможет.