Ефемерні пристрої та пристрої ebs можуть приймати майже будь-яке ім'я файлу пристрою, що має літери, тому не покладайтеся лише на ім’я пристрою. Назва пристрою важлива для визначення того, чи він ефемерний, чи ні, як я викладу нижче. Покладатися на назву точки кріплення зі словами "ефемер" або "ebs" також не є надійним.
Хоча певне це можна зробити за допомогою графічного інтерфейсу EC2, кілька команд все-таки потрібно буде запустити на самому сервері, тому тут я просто даю вам метод «весь командний рядок». Я наведу вам приклади з AMI з підтримкою m3.medium з мінімальним 6,5 екземпляром (тобто ефемерним), підтримуваним 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
Для порівняння, нижче наведено приклад виведення з підтримуваного EBS сервера CentOS з лише томами EBS (без ефемерних дисків):
ami
ebs2
ebs3
Пізніше я повернусь до резервного примірника EBS з томами EBS. Наразі продовжимо з оригінальним прикладом AMI, збереженим у оригінальному магазині екземпляра, який показує нам ефемерний привід.
Щоб дізнатись, який файл пристрою відображається у вашому ефемерному диску, запустіть wget ще раз, додавши до URL-адреси ім’я ефемерного диска, як було виявлено у №2 вище:
3) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ephemeral0 -O -
і, у цьому прикладі вихід є / був:
sdb
Це підкреслює мою точку вище, що ви не можете припустити, що / dev / sdb через / dev / sde є пристроями ebs. Це може бути правдою, що / dev / xvdb through / 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. Ми вже досліджували ефемери0, тому давайте вивчимо 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 чи резервне копіювання магазину інстанцій. У нас є ще одна команда для запуску.
6) wget -q 169.254.169.254/latest/meta-data/ami-manifest-path -O -
Я впевнений , що при підтримці EBS Амі не має маніфест шляху , тому що обсяги зберігати тільки , наприклад , мати маніфест (маніфест перераховані імена і шлях пучок сегментів AMI в S3). У випадках, які я перевірив, результат №6 вище при запуску і зберіганні ami ami є чимось схожим на:
someamibucketname/someamidescription/someamidescription.manifest.xml
тоді як, коли №6 працює проти AMI, підтримуваного EBS, ви отримуєте:
(unknown)
