Os dispositivos efêmeros e ebs podem ter praticamente qualquer nome de arquivo com dispositivo com letras, portanto, não confie apenas no nome do dispositivo. O nome do dispositivo é importante para determinar se é efêmero ou não, no entanto, como descreverei abaixo. Confiar em um nome de ponto de montagem com as palavras 'efêmero' ou 'ebs' também não é confiável.
Embora um pouco disso possa ser feito através da GUI do EC2, alguns comandos ainda precisam ser executados no próprio servidor; portanto, aqui, apenas forneci um método 'toda a linha de comando'. Vou dar exemplos de uma AMI suportada no mínimo de 6,5 instâncias do m3.medium CentOS (isto é, efêmera) suportada.
1) Instale o utilitário wget com yum install -y wget
2) Executar wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ -O -
Neste exemplo de instância armazenada AMI - a saída para o comando # 2 acima é:
ami
ephemeral0
Para fins de comparação, abaixo está um exemplo de saída de um servidor CentOS suportado pelo EBS com apenas volumes EBS (sem unidades efêmeras):
ami
ebs2
ebs3
Voltarei à instância suportada pelo EBS com volumes EBS posteriormente. Por enquanto, vamos continuar com o exemplo da AMI suportada pelo armazenamento de instância original que nos mostra uma unidade efêmera.
Para descobrir qual arquivo de dispositivo está mapeado para sua unidade efêmera, execute o wget novamente, desta vez adicionando o nome da unidade efêmera, conforme descoberto no item 2 acima, ao URL:
3) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ephemeral0 -O -
e, neste exemplo, a saída é / era:
sdb
Isso ressalta meu argumento acima: você não pode assumir que / dev / sdb através de / dev / sde são dispositivos ebs. Ele pode ser verdade que / dev / xvdb através de / dev / xvde são EBS - mas meus sistemas sempre começam com / dev / xvde1 , então a existência dessas cartas dispositivo provavelmente depende do sistema operativo, região, AMI, etc, você está usando. Como um aparte, você pode executar # 3 contra nomes de 'ebs', se houver (por exemplo ebs2), e produzirá resultados semelhantes.
4) Em seguida, execute lsblk
Nesse caso, a saída é assim:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvde1 202:65 0 8G 0 disk /
xvdf 202:80 0 4G 0 disk
Isso ressalta meu argumento de cima: você não pode confiar em um ponto de montagem para dizer se um dispositivo é efêmero ou não.
Você também notará que o mapeamento entre as letras de volume do dispositivo EC2 e as letras de mapeamento do SO não corresponde. Uma pequena parte das boas notícias aqui é que as letras da unidade serão incrementadas na mesma ordem, mesmo que as próprias letras não correspondam. Então, vamos pegar a letra da "outra" unidade nos metadados de nossos mapeamentos de dispositivos. Como você viu acima, havia dois mapeamentos de dispositivos, um chamado amie o outro chamado ephemeral0. Já examinamos efêmero0, então vamos examinar o ami:
5) wget -q 169.254.169.254/latest/meta-data/block-device-mapping/ami -O -
A saída é / foi a seguinte:
sda1
Podemos concluir com segurança que a letra mais baixa no mapeamento do sistema operacional é a letra mais baixa do mapeamento do dispositivo de bloco EC2 e podemos aumentar a partir daí. Portanto:
/dev/sda1 = /dev/xvde1 e /dev/sdb = /dev/xvdf
Por último, mas não menos importante - você notará que o mapeamento do dispositivo de bloco aminão se presta imediatamente a ser suportado pelo EBS ou pelo Repositório de Instâncias. Temos mais um comando para executar.
6) wget -q 169.254.169.254/latest/meta-data/ami-manifest-path -O -
Estou certo de que as AMIs suportadas pelo EBS não têm um caminho de manifesto porque apenas os volumes de armazenamento de instância têm um manifesto (o manifesto lista os nomes e o caminho dos segmentos de pacote configurável da AMI no S3). Nos casos que eu verifiquei, o resultado do item 6 acima, quando executado contra a loja de instância ami, é algo semelhante a:
someamibucketname/someamidescription/someamidescription.manifest.xml
enquanto que, quando o # 6 é executado em uma AMI suportada pelo EBS, você obtém:
(unknown)
