I dispositivi effimeri ed ebs possono assumere praticamente qualsiasi nome di file di dispositivo con lettere, quindi non fare affidamento solo sul nome del dispositivo. Il nome del dispositivo è importante per determinare se è effimero o no, come illustrerò di seguito. Affidarsi al nome di un mount point con le parole "effimero" o "ebs" non è altrettanto affidabile.
Anche se parte di questo può essere fatto tramite la GUI di EC2, alcuni comandi dovrebbero comunque essere eseguiti sul server stesso, quindi qui ti do solo un metodo "tutto a riga di comando". Ti fornirò esempi da un negozio con memoria m3.medium CentOS minimal 6.5 (ovvero effimero) supportato da AMI.
1) Installa l'utility wget con yum install -y wget
2) Esegui wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ -O -
In questo esempio di archivio supportato AMI - l'output del comando n. 2 sopra è:
ami
ephemeral0
A scopo di confronto, di seguito è riportato un esempio di output da un server CentOS supportato da EBS con solo volumi EBS (senza unità temporanee):
ami
ebs2
ebs3
Tornerò all'istanza supportata da EBS con i volumi EBS più tardi. Per ora, continuiamo con l'esempio AMI supportato dall'archivio di istanze originale che ci mostra un'unità effimera.
Per scoprire quale file del dispositivo è mappato sull'unità effimera, esegui di nuovo wget, questa volta aggiungendo il nome dell'unità effimera come scoperto nel numero 2 sopra all'URL:
3) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ephemeral0 -O -
e, in questo esempio, l'output è / era:
sdb
Questo sottolinea il mio punto sopra che non si può presumere che / dev / sdb tramite / dev / sde siano dispositivi ebs. Esso potrebbe essere vero che / dev / xvdb attraverso / dev / xvde sono EBS - ma i miei sistemi iniziano sempre con / dev / xvde1 , così l'esistenza di quelle lettere dispositivo probabilmente dipende dal sistema operativo, regione, AMI, ecc, che si sta utilizzando. Per inciso, puoi eseguire # 3 contro nomi "ebs", se presenti (es. ebs2), E produrre un risultato simile.
4) Quindi, esegui lsblk
In questo caso, l'output è simile al seguente:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvde1 202:65 0 8G 0 disk /
xvdf 202:80 0 4G 0 disk
Ciò sottolinea il mio punto dall'alto che non puoi fare affidamento su un mount point per dirti se un dispositivo è effimero o no.
Noterai anche che la mappatura tra le lettere di volume del dispositivo EC2 e le lettere di mappatura del sistema operativo non corrispondono. Un piccolo frammento di buone notizie qui è che le lettere di unità aumenteranno nello stesso ordine, anche se le lettere stesse non corrispondono. Quindi, prendiamo la "altra" lettera di unità dai nostri metadati di mappatura dei dispositivi. Come hai visto sopra, c'erano due mappature dei dispositivi, uno chiamato amie l'altro chiamato ephemeral0. Abbiamo già esaminato effimero0, quindi esaminiamo ami:
5) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ami -O -
L'output è / era il seguente:
sda1
Possiamo concludere con sicurezza che la lettera più bassa nella mappatura del sistema operativo è la lettera più bassa della mappatura del dispositivo a blocchi EC2, e possiamo aumentare da lì verso l'alto. Così:
/dev/sda1 = /dev/xvde1 e /dev/sdb = /dev/xvdf
Ultimo ma non meno importante, noterai che la mappatura del dispositivo a blocchi aminon si presta immediatamente al fatto che sia supportato da EBS o da Instance Store. Abbiamo ancora un comando da eseguire.
6) wget -q 169.254.169.254/latest/meta-data/ami-manifest-path -O -
Sono certo che gli AMI supportati da EBS non hanno un percorso manifest perché solo i volumi di archivio di istanze hanno un manifest (il manifest elenca i nomi e il percorso dei segmenti bundle dell'AMI in S3). Nei casi che ho verificato, il risultato di cui sopra # 6 quando viene eseguito e l'ami dell'istanza del negozio è qualcosa di simile a:
someamibucketname/someamidescription/someamidescription.manifest.xml
mentre quando # 6 viene eseguito contro un AMI supportato da EBS si ottiene:
(unknown)
