Adicionar um disco a uma VM com Linux

  • Artigo

Aplica-se a: ✔️ Conjuntos de dimensionamento flexíveis de VMs ✔️ do Linux

Este artigo mostra-lhe como anexar um disco persistente à VM para que possa preservar os seus dados, mesmo que a VM seja novamente aprovisionada devido a manutenção ou redimensionamento.

Anexar um novo disco a uma VM

Se quiser adicionar um disco de dados novo e vazio na VM, utilize o comando az vm disk attach com o --new parâmetro . Se a VM estiver numa Zona de Disponibilidade, o disco é criado automaticamente na mesma zona que a VM. Para obter mais informações, veja Descrição geral do Zonas de Disponibilidade. O exemplo seguinte cria um disco com o nome myDataDisk com 50 Gb de tamanho:

az vm disk attach \
   -g myResourceGroup \
   --vm-name myVM \
   --name myDataDisk \
   --new \
   --size-gb 50

Latência mais baixa

Em regiões selecionadas, a latência de anexação do disco foi reduzida, pelo que verá uma melhoria de até 15%. Isto é útil se tiver ativações pós-falha planeadas/não planeadas entre VMs, estiver a dimensionar a carga de trabalho ou estiver a executar uma carga de trabalho com estado de alta escala, como Azure Kubernetes Service. No entanto, esta melhoria está limitada ao comando explícito de anexação do disco, az vm disk attach. Não verá a melhoria de desempenho se chamar um comando que possa executar implicitamente uma anexação, como az vm update. Não precisa de efetuar nenhuma ação que não seja chamar o comando de anexação explícito para ver esta melhoria.

A latência inferior está atualmente disponível em todas as regiões públicas, exceto em:

  • Canadá Central
  • E.U.A. Central
  • E.U.A. Leste
  • E.U.A. Leste 2
  • E.U.A. Centro-Sul
  • E.U.A. Oeste 2
  • Norte da Alemanha
  • Jio, Oeste da Índia
  • Europa do Norte
  • Europa Ocidental

Anexar um disco existente

Para anexar um disco existente, localize o ID do disco e transmita o ID para o comando az vm disk attach . O exemplo seguinte consulta um disco com o nome myDataDisk em myResourceGroup e, em seguida, anexa-o à VM com o nome myVM:

diskId=$(az disk show -g myResourceGroup -n myDataDisk --query 'id' -o tsv)

az vm disk attach -g myResourceGroup --vm-name myVM --name $diskId

Formatar e montar o disco

Para particionar, formatar e montar o novo disco para que a VM do Linux possa utilizá-lo, aceda SSH à VM. Para obter mais informações, veja como utilizar SSH com Linux no Azure. O exemplo seguinte liga-se a uma VM com o endereço IP público 10.123.123.25 com o nome de utilizador azureuser:

ssh azureuser@10.123.123.25

Localizar o disco

Depois de ligar à VM, localize o disco. Neste exemplo, estamos a utilizar para listar lsblk os discos.

lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd"

O resultado é semelhante ao seguinte exemplo:

sda     0:0:0:0      30G
├─sda1             29.9G /
├─sda14               4M
└─sda15             106M /boot/efi
sdb     1:0:1:0      14G
└─sdb1               14G /mnt
sdc     3:0:0:0      50G

Aqui, sdc é o disco que queremos, porque é 50G. Se adicionar vários discos e não tiver a certeza de que disco se baseia apenas no tamanho, pode aceder à página da VM no portal, selecionar Discos e verificar o número LUN do disco em Discos de dados. Compare o número LUN do portal com o último número da parte HTCL da saída, que é o LUN. Outra opção é listar os conteúdos do /dev/disk/azure/scsi1 diretório:

ls -l /dev/disk/azure/scsi1

O resultado deve ser semelhante ao seguinte exemplo:

lrwxrwxrwx 1 root root 12 Mar 28 19:41 lun0 -> ../../../sdc

Formatar o disco

Formate o disco com parted, se o tamanho do disco for de dois tebibytes (TiB) ou maior, tem de utilizar a criação de partições GPT, se estiver abaixo de 2TiB, pode utilizar a criação de partições MBR ou GPT.

Nota

Recomenda-se que utilize a versão parted mais recente que está disponível para a distribuição. Se o tamanho do disco for de 2 tebibytes (TiB) ou superior, tem de utilizar a criação de partições GPT. Se o tamanho do disco for inferior a 2 TiB, pode utilizar a criação de partições MBR ou GPT.

O exemplo seguinte utiliza parted em /dev/sdc, que é onde o primeiro disco de dados estará normalmente na maioria das VMs. Substitua sdc pela opção correta para o disco. Também estamos a formatá-lo com o sistema de ficheiros XFS .

sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%
sudo partprobe /dev/sdc
sudo mkfs.xfs /dev/sdc1

Utilize o partprobe utilitário para se certificar de que o kernel tem conhecimento da nova partição e do sistema de ficheiros. A não utilização partprobe pode fazer com que os comandos blkid ou lsblk não devolvam imediatamente o UUID do novo sistema de ficheiros.

Montar o disco

Agora, crie um diretório para montar o sistema de ficheiros com mkdir. O exemplo seguinte cria um diretório em /datadrive:

sudo mkdir /datadrive

Utilize mount para, em seguida, montar o sistema de ficheiros. O exemplo seguinte monta a /dev/sdc1 partição no /datadrive ponto de montagem:

sudo mount /dev/sdc1 /datadrive

Manter a montagem

Para garantir que a unidade é montada novamente automaticamente após um reinício, tem de ser adicionada ao /etc/fstab ficheiro. Também é altamente recomendado que o UUID (Universally Unique Identifier) seja utilizado para /etc/fstab fazer referência à unidade em vez de apenas ao nome do dispositivo (por exemplo, /dev/sdc1). Se o SO detetar um erro do disco durante o arranque, ao utilizar o UUID evitará que o disco incorreto seja montado numa determinada localização. Os restantes discos de dados serão, em seguida, atribuídos aos mesmos IDs de dispositivos. Para localizar o UUID da nova unidade, utilize o utilitário blkid:

sudo blkid

O resultado é semelhante ao seguinte exemplo:

/dev/sda1: LABEL="cloudimg-rootfs" UUID="11111111-1b1b-1c1c-1d1d-1e1e1e1e1e1e" TYPE="ext4" PARTUUID="1a1b1c1d-11aa-1234-1a1a1a1a1a1a"
/dev/sda15: LABEL="UEFI" UUID="BCD7-96A6" TYPE="vfat" PARTUUID="1e1g1cg1h-11aa-1234-1u1u1a1a1u1u"
/dev/sdb1: UUID="22222222-2b2b-2c2c-2d2d-2e2e2e2e2e2e" TYPE="ext4" TYPE="ext4" PARTUUID="1a2b3c4d-01"
/dev/sda14: PARTUUID="2e2g2cg2h-11aa-1234-1u1u1a1a1u1u"
/dev/sdc1: UUID="33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e" TYPE="xfs" PARTLABEL="xfspart" PARTUUID="c1c2c3c4-1234-cdef-asdf3456ghjk"

Nota

A edição imprópria do ficheiro /etc/fstab poderá resultar num sistema não inicializável. Se não tiver a certeza, consulte a documentação de distribuição para obter mais informações sobre como editar corretamente este ficheiro. Também é recomendado que seja criada uma cópia de segurança do /etc/fstab ficheiro antes de editar.

Em seguida, abra o /etc/fstab ficheiro num editor de texto. Adicione uma linha ao final do ficheiro, utilizando o valor UUID para o /dev/sdc1 dispositivo que foi criado nos passos anteriores e o ponto de montagem de /datadrive. Com o exemplo deste artigo, a nova linha terá o seguinte aspeto:

UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,nofail   1   2

Quando terminar de editar o ficheiro, guarde e feche o editor.

Em alternativa, pode executar o seguinte comando para adicionar o disco ao /etc/fstab ficheiro:

echo "UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,nofail   1   2" >> /etc/fstab

Nota

Remover posteriormente um disco de dados sem editar fstab pode fazer com que a VM não arranque. A maioria das distribuições fornece as opções nofail e/ou nobootwait fstab. Estas opções permitem que um sistema arranque mesmo que o disco não seja montado no momento do arranque. Consulte a documentação da sua distribuição para obter mais informações sobre estes parâmetros.

A opção nofail garante que a VM é iniciada mesmo que o sistema de ficheiros esteja danificado ou o disco não exista no momento do arranque. Sem esta opção, poderá encontrar um comportamento conforme descrito em Não é possível fazer SSH para a VM do Linux devido a erros de FSTAB

A Consola de Série da VM do Azure pode ser utilizada para o acesso da consola à VM se a modificação do fstab tiver resultado numa falha de arranque. Estão disponíveis mais detalhes na documentação da Consola de Série.

Suporte TRIM/UNMAP para Linux no Azure

Alguns kernels do Linux suportam operações TRIM/UNMAP para eliminar blocos não utilizados no disco. Esta funcionalidade é essencialmente útil para informar o Azure de que as páginas eliminadas já não são válidas e podem ser eliminadas. Esta funcionalidade pode poupar dinheiro em discos que são faturados com base na quantidade de armazenamento consumido, como discos standard não geridos e instantâneos de disco.

Existem duas formas de ativar o suporte TRIM na VM do Linux. Como habitualmente, consulte a sua distribuição para obter a abordagem recomendada:

  • Utilize a opção discard de montagem em /etc/fstab, por exemplo:

    UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,discard   1   2

  • Em alguns casos, a opção discard pode ter implicações de desempenho. Em alternativa, pode executar o comando manualmente a fstrim partir da linha de comandos ou adicioná-lo ao crontab para ser executado regularmente:

sudo apt install util-linux
sudo fstrim /datadrive

Resolução de problemas

Ao adicionar discos de dados a uma VM do Linux, poderá encontrar erros se um disco não existir no LUN 0. Se estiver a adicionar um disco manualmente com o az vm disk attach -new comando e especificar um LUN (--lun) em vez de permitir que a plataforma do Azure determine o LUN adequado, tenha em atenção que um disco já existe/existirá no LUN 0.

Considere o exemplo seguinte que mostra um fragmento da saída de lsscsi:

[5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc 
[5:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd

Os dois discos de dados existem em LUN 0 e LUN 1 (a primeira coluna nos detalhes [host:channel:target:lun]de lsscsi saída ). Ambos os discos devem estar acessíveis a partir da VM. Se tiver especificado manualmente o primeiro disco a ser adicionado ao LUN 1 e ao segundo disco no LUN 2, poderá não ver os discos corretamente a partir da VM.

Nota

O valor do Azure host é 5 nestes exemplos, mas pode variar consoante o tipo de armazenamento que selecionar.

Este comportamento do disco não é um problema do Azure, mas a forma como o kernel do Linux segue as especificações do SCSI. Quando o kernel do Linux analisa o barramento SCSI para dispositivos ligados, é necessário encontrar um dispositivo no LUN 0 para que o sistema continue a procurar dispositivos adicionais. Como tal:

  • Reveja a saída de depois de adicionar um disco de lsscsi dados para verificar se tem um disco no LUN 0.
  • Se o disco não aparecer corretamente na VM, verifique se existe um disco no LUN 0.

Passos seguintes