Эфемерные диски Amazon AWS и 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
Любопытно, что raid читает примерно так же быстро, как и более быстрые диски, и не ограничивается скоростью самого медленного диска.
/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
Выключение / включение возвращает ухудшенный raidset, но приложение все равно может работать, хотя и медленнее. Я избегаю затрат на ожидание в течение 5-10 минут, и я могу повторно добавить эфемерные диски в рейд на лету без перезапуска приложения.
Так что, хотя это, кажется, работает отлично, есть ли что-то, что я пропустил или не учитывается?
Хм, я не уверен, что хочу смешать два таких разных тома в одном RAID1. Если вы сделаете это, половина ваших запросов будет обслуживаться более медленным EBS, а половина - более быстрым хранилищем экземпляров, что может привести к довольно непредсказуемой производительности. Я бы посмотрел на стандартные инструменты для достижения лучшей производительности.
Посмотрите на Provisioned IOPS EBS disks (если вам нужен высокий IO с произвольным доступом) или Throughput optimized EBS (если вы последовательно читаем большие файлы). Они могут обеспечить необходимую вам производительность прямо из коробки. Цена указана здесь .
Вам также следует обратить внимание на некоторое кеширование , тем более, что, как вы говорите, это в основном содержимое только для чтения. Каждый раз, когда файл нужен, вы можете посмотреть в каталоге локального кеша на временном хранилище и, если он там, обслуживать его оттуда. Если нет, возьмите его с EBS и сохраните копию в кеше. Особенно, если все это только для чтения, это должен быть довольно простой уровень кэширования.
Или, если файлы в EBS являются файлами базы данных (что, как я подозреваю, может иметь место) кэширует результаты ваших запросов или обработки в Memcache или Redis или в собственном кэше базы данных (например, MySQL Query Cache ).
Надеюсь, что это поможет :)
40 ГБ достаточно мало для RAM-дисков, которые работают быстрее, чем рабочие диски. Как долго будет работать ваше приложение и стоит ли платить за экземпляр с увеличенным объемом памяти?
24x7 может быть слишком дорогостоящим. Но 40 ГБ в пределах досягаемости.
В качестве бонуса вы получите больше ядер.
Я согласен с кешированием запросов для детерминированных запросов, и любой вид буферизации со временем поможет.
მე ... არ გამოიყენეთ RAID1 ტომი, თუნდაც - ჩაწერეთ ძირითადად . შესრულების დეგრადაცია, როდესაც კომპლექტი ხელახლა აშენებს, მაღიზიანებს.
ის, რასაც მე გირჩევთ გირჩევთ შეისწავლოთ, არის bcache . მივხვდი, რომ ეს ძალიან სასარგებლოა ისეთ სიტუაციებში, როდესაც SSD– ებზე მაქვს წვდომა, მაგრამ ასევე მაქვს ძალიან დიდი მონაცემების შესანახად (როგორც წესი, ძალიან დიდი PostgreSQL მონაცემთა ბაზები), რომელთა ყიდვაც არ არის ეფექტური SSD- ები. მე ის მხოლოდ "მუდმივ" რეჟიმში გამოვიყენე, სადაც ის იყენებს SSD- ებს, როგორც უკუკავშირის დამახსოვრების მეხსიერების მეხსიერებას, მაგრამ მას აქვს რეჟიმი, როდესაც მეხსიერების მეხსიერების ფენა განიხილება, როგორც ეფემერული, და არცერთი ჩანაწერი არ განიხილება დასრულებამდე ფუძემდებლური მუდმივი შენახვის შესახებ.