Urządzenia efemeryczne i ebs mogą przyjmować dowolną literową nazwę pliku urządzenia, więc nie polegaj wyłącznie na nazwie urządzenia. Nazwa urządzenia jest ważna przy ustalaniu, czy jest efemeryczna, czy nie, jak nakreślę poniżej. Poleganie na nazwie punktu montowania ze słowami „efemeryczny” lub „ebs” również nie jest wiarygodne.
Chociaż niektóre z tych czynności można wykonać za pomocą graficznego interfejsu użytkownika EC2, kilka poleceń nadal musiałoby być uruchamianych na samym serwerze, więc tutaj podaję tylko metodę „całego wiersza poleceń”. Dam ci przykłady ze sklepu instancji m3.medium CentOS minimalna wersja 6.5 (tj. Efemeryczna) wspierana przez AMI.
1) Zainstaluj narzędzie wget za pomocą yum install -y wget
2) Uruchom wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ -O -
W tym przykładzie AMI wspiera sklep - dane wyjściowe dla polecenia nr 2 powyżej to:
ami
ephemeral0
Dla celów porównawczych poniżej przedstawiono przykładowe dane wyjściowe z serwera CentOS wspieranego przez EBS tylko z woluminami EBS (bez dysków efemerycznych):
ami
ebs2
ebs3
Wrócę do kopii zapasowej EBS z woluminami EBS później. Na razie kontynuujmy z przykładem AMI opartym na oryginalnym magazynie instancji, który pokazuje efemeryczny dysk.
Aby dowiedzieć się, który plik urządzenia jest zamapowany na efemeryczny dysk, uruchom ponownie wget, tym razem dodając nazwę efemerycznego dysku odkrytego w punkcie 2 powyżej do adresu URL:
3) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ephemeral0 -O -
a w tym przykładzie dane wyjściowe to / was:
sdb
Podkreśla to mój punkt powyżej, że nie można zakładać, że / dev / sdb przez / dev / sde są urządzeniami ebs. Być może prawdą jest, że / dev / xvdb przez / dev / xvde to ebs - ale moje systemy zawsze zaczynają się od / dev / xvde1 , więc istnienie tych liter urządzeń prawdopodobnie zależy od systemu operacyjnego, regionu, AMI itp., Którego używasz. Nawiasem mówiąc, możesz uruchomić numer 3 w stosunku do nazw „ebs”, jeśli istnieją (np. ebs2), I uzyska podobne wyniki.
4) Następnie uruchom lsblk
W takim przypadku dane wyjściowe wyglądają tak:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvde1 202:65 0 8G 0 disk /
xvdf 202:80 0 4G 0 disk
To podkreśla mój punkt widzenia z góry, że nie można polegać na punkcie montowania, aby powiedzieć, czy urządzenie jest efemeryczne, czy nie.
Zauważysz również, że odwzorowanie między literami woluminu urządzenia EC2 a literami odwzorowania systemu operacyjnego nie jest zgodne. Mały kawałek dobrych wiadomości tutaj jest taki, że litery dysków będą rosły w tej samej kolejności, nawet jeśli same litery nie będą pasować. Pobierzmy więc „inną” literę dysku z naszych meta-danych mapowań urządzeń. Jak widzieliśmy powyżej, były dwa mapowania urządzeń, jedno wywołane, amia drugie wywołane ephemeral0. Sprawdziliśmy już efemeryczny0, więc przyjrzyjmy się ami:
5) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ami -O -
Dane wyjściowe są następujące:
sda1
Możemy śmiało stwierdzić, że najniższa litera w odwzorowaniu systemu operacyjnego to najniższa litera odwzorowania urządzenia blokowego EC2 i od tego momentu możemy zwiększać w górę. A zatem:
/dev/sda1 = /dev/xvde1 i /dev/sdb = /dev/xvdf
Last but not least - zauważysz, że mapowanie urządzeń blokowych aminie pozwala od razu stwierdzić, czy jest ono wspierane przez EBS, czy przez Instance Store. Mamy jeszcze jedno polecenie do uruchomienia.
6) wget -q 169.254.169.254/latest/meta-data/ami-manifest-path -O -
Jestem pewien, że AMI wspierane przez EBS nie mają ścieżki manifestu, ponieważ manifest ma tylko woluminy magazynu instancji (manifest zawiera nazwy i ścieżkę segmentów pakietu AMI w S3). W przypadkach, które sprawdziłem, wynik z punktu 6 powyżej, gdy działam przeciwko i przechowuję instancję ami, jest podobny do:
someamibucketname/someamidescription/someamidescription.manifest.xml
podczas gdy # 6 jest uruchamiany przeciwko AMI wspieranemu przez EBS, otrzymujesz:
(unknown)
