Устройства Ephemeral и ebs могут принимать практически любое буквенное имя файла устройства, поэтому не следует полагаться только на имя устройства. Однако имя устройства важно для определения того, является ли оно эфемерным или нет, как я опишу ниже. Полагаться на имя точки монтирования со словами «эфемерный» или «ebs» также ненадежно.
Хотя некоторые из них могут быть выполнены с помощью графического интерфейса EC2, на самом сервере нужно будет выполнить несколько команд, поэтому здесь я просто дам вам метод «все из командной строки». Я дам вам примеры из минимального 6.5 экземпляра хранилища m3.medium CentOS (т.е. временного) AMI.
1) Установите утилиту wget с помощью yum install -y wget
2) Беги wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ -O -
В этом примере AMI с сохранением хранилища экземпляров - вывод команды № 2 выше:
ami
ephemeral0
Для сравнения ниже приведен пример выходных данных с сервера CentOS, поддерживаемого EBS, только с томами EBS (без временных дисков):
ami
ebs2
ebs3
Я вернусь к экземпляру, поддерживаемому EBS, с томами EBS позже. А сейчас давайте продолжим с оригинальным примером AMI, поддерживаемым хранилищем экземпляров, который показывает нам эфемерный драйв.
Чтобы узнать, какой файл устройства сопоставлен с вашим эфемерным диском, снова запустите wget, на этот раз добавив имя эфемерного диска, обнаруженное в # 2 выше, к URL:
3) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ephemeral0 -O -
и в этом примере выводом является / было:
sdb
Это подчеркивает мою точку зрения выше, что вы не можете предполагать, что / dev / sdb через / dev / sde являются устройствами ebs. Это может быть верно , что / DEV / xvdb через / DEV / xvde является EBS - но мои системы всегда начинаются с / DEV / xvde1 , поэтому наличие этих букв устройств , вероятно , зависит от операционной системы, области, AMI и т.д., которые вы используете. Кроме того, вы можете запустить # 3 для имен 'ebs', если таковые имеются (например ebs2), и даст аналогичный результат.
4) Далее беги lsblk
В этом случае вывод выглядит так:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvde1 202:65 0 8G 0 disk /
xvdf 202:80 0 4G 0 disk
Это подчеркивает мою точку зрения сверху, что вы не можете полагаться на точку монтирования, чтобы сказать вам, является ли устройство эфемерным или нет.
Вы также заметите, что сопоставление между буквами тома устройства EC2 и буквами сопоставления ОС не совпадают. Небольшая новость в том, что буквы дисков будут увеличиваться в том же порядке, даже если сами буквы не совпадают. Итак, давайте получим букву «другого» диска из наших метаданных сопоставлений устройств. Как вы видели выше, было два сопоставления устройств: одно вызвано, amiа другое вызвано ephemeral0. Мы уже исследовали ephemeral0, поэтому давайте рассмотрим ami:
5) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ami -O -
Вывод / был следующим:
sda1
Мы можем с уверенностью заключить, что самая низкая буква в отображении ОС - это самая низкая буква в отображении блочных устройств EC2, и мы можем увеличивать оттуда. Таким образом:
/dev/sda1 = /dev/xvde1 а также /dev/sdb = /dev/xvdf
И последнее, но не менее важное: вы заметите, что сопоставление блочных устройств amiне сразу поддается поддержке EBS или Instance Store. У нас есть еще одна команда для запуска.
6) wget -q 169.254.169.254/latest/meta-data/ami-manifest-path -O -
Я уверен, что поддерживаемые EBS AMI не имеют пути манифеста, потому что манифест есть только в томах хранилища экземпляров (в манифесте перечислены имена и пути сегментов пакета AMI в S3). В случаях, которые я проверил, результат # 6 выше при запуске против ami хранилища экземпляров выглядит примерно так:
someamibucketname/someamidescription/someamidescription.manifest.xml
тогда как, когда # 6 запускается против поддерживаемого EBS AMI, вы получаете:
(unknown)
