Execute uma VM Linux no Azure

Azure Backup

Azure Bastion

Armazenamento de Blobs do Azure

Azure Resource Manager

Armazenamento do Azure

Máquinas Virtuais do Microsoft Azure

Para provisionar uma máquina virtual (VM) no Azure, precisas de mais componentes do que a própria VM. Uma implementação completa inclui recursos de rede e armazenamento. Este artigo descreve as melhores práticas para correr uma VM Linux segura no Azure.

Arquitetura

Descarregue um ficheiro Visio desta arquitetura.

Workflow

Este exemplo mostra uma implementação básica que utiliza os componentes necessários para uma única VM. A VM pode executar cargas de trabalho e aceder à internet pública, evitando a exposição direta a ameaças externas. Nesta arquitetura:

As cargas de trabalho na VM não têm exposição direta à internet. O acesso está restringido a recursos na mesma rede virtual ou numa rede virtual em emparelhamento, por exemplo, numa configuração hub-and-spoke.
Geres a VM usando o Azure Bastion via Secure Shell (SSH). Não há acesso direto da internet pública à VM para a gestão.
O Gateway de Tradução de Endereços de Rede (NAT) e o seu endereço IP público associado fornecem acesso externo à internet de saída.

Componentes

Essa arquitetura usa os seguintes componentes.

Grupo de recursos

Um grupo de recursos é um contentor lógico que contém recursos Azure relacionados. Os grupos de recursos permitem-lhe implementar, monitorizar e eliminar recursos relacionados em conjunto, e acompanhar os seus custos como unidade.

Em geral, agrupe os recursos por ciclo de vida e propriedade partilhados. Use nomes consistentes e descritivos para os recursos que os tornem mais fáceis de identificar e compreender. Para obter mais informações, consulte Definir a sua convenção de nomenclatura.

Máquina virtual

Pode provisionar uma VM a partir de uma lista de imagens publicadas, uma imagem gerida personalizada ou um disco rígido virtual (VHD) carregado para o Armazenamento de Blobs do Azure. O Azure suporta distribuições Linux populares, incluindo Debian, Red Hat Enterprise Linux (RHEL) e Ubuntu. Para saber mais, consulte Distribuições Linux endossadas.

O Azure oferece muitos tamanhos diferentes de VMs. Se transferir uma carga de trabalho existente para o Azure, comece pelo tamanho da VM que mais corresponde aos seus servidores on-premises. Depois de implantares a VM, mede o desempenho real da tua carga de trabalho em termos de CPU, memória e operações de entrada-saída de disco por segundo (IOPS), e ajusta o tamanho conforme necessário.

Escolha uma região do Azure que esteja mais próxima dos seus utilizadores internos ou clientes. Nem todos os tamanhos de VM estão disponíveis em todas as regiões. Para obter mais informações, consulte Geografias do Azure. Para uma lista dos tamanhos de VM disponíveis numa região específica, execute o seguinte comando a partir da CLI do Azure:

az vm list-sizes --location <location>

Para informações sobre como escolher uma imagem de VM publicada, consulte Encontrar informação de imagem no Azure Marketplace.

Discos

Para o melhor desempenho de entrada-saída (I/O) do disco, recomendamos SSDs Premium, que armazenam dados em unidades de estado sólido (SSDs). A capacidade do disco provisionado determina o custo, IOPS e a largura de banda (taxa de transferência de dados). Considere os três fatores ao selecionar o tamanho do disco. Os SSDs premium incluem free bursting, que ajuda a satisfazer a procura máxima sem sobreprovisionamento e reduz o custo da capacidade não utilizada quando combinado com uma compreensão dos padrões de carga de trabalho.

Nota

Discos premium SSD v2 e Ultra só podem ser usados para discos de dados. Não são suportados em discos do sistema operativo (SO).

Os discos gerenciados simplificam o gerenciamento de discos , manipulando o armazenamento para você. Discos geridos não exigem uma conta de armazenamento. Você especifica o tamanho e o tipo de disco e ele é implantado como um recurso altamente disponível. Os discos geridos também reduzem custos ao fornecer o desempenho necessário sem sobreprovisionamento, o que ajuda a evitar pagar por capacidade provisionada não utilizada.

Por defeito, o disco do sistema operativo é um disco gerido armazenado em Armazenamento de Discos do Azure, pelo que persiste mesmo quando a máquina anfitriã está fora de serviço. Para cargas de trabalho sem estado, onde se deseja provisionamento rápido e sem persistência do sistema operativo, utilize-se discos efémeros do sistema operativo. Estes discos colocam a imagem do sistema operativo no armazenamento local do host da VM em vez do Armazenamento do Azure remoto, o que reduz a latência de leitura, acelera a reimagem e elimina o custo gerido do disco. No entanto, todos os dados num disco efémero do sistema operativo são perdidos em eventos de paragem (desalocar), reimagem ou manutenção do host. Os discos efémeros do sistema operativo não suportam snapshots nem Azure Backup. Use discos efémeros do sistema operativo apenas quando as VMs estiverem completamente reimplantáveis a partir da automação.

Por predefinição, muitas imagens do Linux não configuram área de swap. Se a sua carga de trabalho exigir troca, crie-a no disco temporário usando cloud-init em vez de no disco do sistema operativo ou num disco de dados.

Recomendamos que crie um ou mais discos de dados para os dados da aplicação. Os discos de dados são discos persistentes geridos, suportados pelo Storage.

Quando crias um disco, não está formatado. Iniciar sessão na VM para formatar o disco. No shell do Linux, os discos de dados são apresentados como /dev/sdc, /dev/sdd, e letras posteriores na série. Pode executar lsblk para listar os dispositivos de bloqueio, incluindo os discos. Para utilizar um disco de dados, crie uma partição e um sistema de ficheiros e monte o disco. Por exemplo:

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

Quando adiciona um disco de dados, é-lhe atribuído um número de unidade lógica (LUN). Também pode especificar o ID LUN se, por exemplo, estiver a substituir um disco e quiser manter o mesmo ID LUN, ou se tiver uma aplicação que procure um ID LUN específico. No entanto, os IDs LUN devem ser únicos para cada disco.

Para discos de armazenamento Premium, pode querer alterar o agendador de I/O para otimizar o desempenho nos SSDs. Uma recomendação comum é usar o agendador No Operation (NOOP) para SSDs, mas deve usar uma ferramenta como o iostat para monitorizar o desempenho da I/O do disco para a sua carga de trabalho.

Muitas VMs são criadas com um disco temporário, que é armazenado numa unidade física na máquina anfitriã. Não está guardado no Armazenamento e pode ser eliminado durante reinicios e outros eventos do ciclo de vida da VM. Utilize este disco apenas para dados temporários, tais como ficheiros de paginação ou de troca. Para as VMs do Linux, o disco temporário é /dev/disk/azure/resource-part1 e está montado em /mnt/resource ou em /mnt.

Rede

Os componentes de rede incluem os seguintes recursos:

Rede virtual: Cada VM é implementada numa rede virtual que é segmentada em sub-redes.
Placa de interface de rede (NIC): A NIC liga a VM à rede virtual e gere todo o tráfego de entrada e saída. Cada tamanho de VM define um número máximo de NICs.
Endereço IP público: Um endereço IP público pode ser usado para comunicar com a VM a partir de fora do Azure via SSH. No entanto, esta opção é desencorajada porque representa um potencial risco de segurança.

Warning

Evite anexar um endereço IP público diretamente a uma VM. Só o fazem em circunstâncias extremas e incluem outras medidas de segurança, como a utilização de grupos de segurança de rede (NSGs) para filtrar o tráfego.

Para acesso de gestão a uma VM, use o Azure Bastion para acesso SSH baseado em browser, ou ligue-se privadamente através de uma VPN ou Azure ExpressRoute.
- O endereço IP público pode ser dinâmico ou estático. Por predefinição, é dinâmico. Reserve um endereço IP estático quando precisar de um endereço IP fixo que não mude, por exemplo, se precisar de criar um registo DNS 'A' ou adicionar o endereço IP a uma lista segura.
- Também pode criar um nome de domínio completamente qualificado (FQDN) para o endereço IP. Depois, pode registar um registo CNAME no DNS que aponte para o FQDN. Para mais informações, consulte Criar um nome de domínio totalmente qualificado para uma VM.
NSG: Use NSGs para permitir ou negar o tráfego de rede para VMs e sub-redes. Associe-as às sub-redes ou às NICs individuais associadas a VMs.

Todos os NSGs contêm um conjunto de regras de segurança por defeito, incluindo uma regra que bloqueia todo o tráfego de internet de entrada. Não podes eliminar as regras padrão, mas podes sobrepê-las com outras regras. Por exemplo, pode criar regras que permitam o tráfego de entrada de internet para portas específicas, como a porta 443 para HTTPS.
Azure Network Address Translation (NAT) Gateway:O Azure NAT Gateway permite que todas as instâncias de uma sub-rede privada se conectem de saída à internet, mantendo-se totalmente privadas. Somente os pacotes que chegam como pacotes de resposta a uma conexão de saída podem passar por um gateway NAT. Não são permitidas ligações de entrada não solicitadas a partir da Internet.

Nota

Para melhorar a segurança padrão, o acesso implícito à Internet para saída está a ser descontinuado para todas as novas redes virtuais. Precisa de configurar explicitamente a conectividade de saída à internet usando outros recursos como NAT Gateway, Azure Standard Load Balancers ou firewalls. Para obter mais informações, consulte Acesso de saída padrão no Azure.
Azure Bastion:Azure Bastion é uma solução totalmente gerida de plataforma como serviço (PaaS) que fornece acesso seguro a VMs através de endereços IP privados. Com essa configuração, as VMs não precisam de um endereço IP público que as exponha à internet, o que aumenta sua postura de segurança. O Azure Bastion fornece conectividade segura Ambiente de Trabalho Remoto Protocol (RDP) ou SSH às suas VMs diretamente através do Transport Layer Security (TLS), utilizando vários métodos, incluindo o portal Azure ou clientes nativos SSH ou RDP.

Operações

Esta secção cobre as principais práticas operacionais para gerir uma VM Linux no Azure.

SSH: Antes de criar uma VM Linux, gere um par de chaves públicas-privadas RSA de 2048 bits. Utilize o ficheiro de chave pública quando criar a VM. Para mais informações, consulte Criar e usar um par de chaves público-privadas SSH.
Diagnóstico: Permitir monitorização e diagnósticos, incluindo métricas básicas de saúde, registos de infraestrutura de diagnóstico e diagnósticos de arranque. Os diagnósticos de arranque podem ajudar a diagnosticar uma falha de arranque se a sua VM ficar num estado em que não arranca. Armazene registos de diagnóstico numa conta de Armazenamento. Uma conta padrão de armazenamento localmente redundante (LRS) é suficiente para os registos de diagnóstico. Para mais informações, consulte Boas práticas para monitorização e diagnóstico.
Disponibilidade:Manutenção planeada ou períodos de inatividade não planeados podem afetar a sua VM. Pode usar os registos de reinício da VM para determinar se a manutenção planeada causou o reinício da VM. Para maior disponibilidade, implemente múltiplas VMs em zonas de disponibilidade dentro de uma região. Esta implantação proporciona um acordo de nível de serviço (SLA) mais elevado. Quando as zonas de disponibilidade não são suportadas, os conjuntos de disponibilidade podem ajudar a fornecer proteção contra falhas do host ou atualizações do host. No entanto, as zonas de disponibilidade são a opção recomendada sempre que possível.
Cópias de segurança: Para se proteger contra a perda acidental de dados, utilize o serviço Azure Backup para efetuar cópias de segurança das suas VMs num armazenamento. Dependendo da região, podes usar armazenamento geo-redundante ou armazenamento redundante por zona para backups. O Azure Backup fornece backups consistentes com a aplicação. Para cargas de trabalho sensíveis ao desempenho ou distribuições Linux especializadas que não suportam agentes de cópia de segurança tradicionais, utilize a funcionalidade de cópia de segurança consistente após falha, sem agente e em vários discos para automatizar a proteção das cópias de segurança sem afetar o desempenho da aplicação.
Parar uma VM: O Azure faz uma distinção entre estados parados e desalocados. És cobrado quando o estado da VM é parado, mas não quando a VM é desalocada. No portal Azure, o botão Stop desaloca a VM. Se desligares a VM através do sistema operativo enquanto estás logado, a VM é parada mas não é dealalocada, por isso ainda pagas.
Apagar uma VM: Se apagares uma VM, podes escolher apagar ou manter os seus discos, o que te permite manter os dados. No entanto, continua a pagar pelos discos. Podes eliminar discos geridos como qualquer outro recurso do Azure. Para impedir a eliminação acidental, utilize um bloqueio de recursos para bloquear o grupo de recursos inteiro ou bloqueie recursos individuais, como a VM.

Alternatives

O Conjuntos de Dimensionamento de Máquinas Virtuais do Azure oferece a capacidade de distribuir cargas de trabalho entre nós. Cargas de trabalho críticas para as operações empresariais nunca devem depender de uma única VM. Pode adicionar ou remover instâncias de VM automaticamente consoante a procura e aumentar a escala em alturas de maior tráfego ou reduzi-la quando o tráfego é menor, para ajudar a minimizar os custos.
O Balanceador de Carga do Azure distribui o tráfego entre múltiplas VMs ou um conjunto de escalas de máquinas virtuais. Pode também ser usado como alternativa a um NAT Gateway para permitir o acesso a uma carga de trabalho a partir da internet, ao mesmo tempo que suporta o acesso de saída.
O Application Gateway fornece funcionalidade de balanceamento de carga ao Balanceador de Carga do Azure para cargas de trabalho HTTP/HTTPS dentro de uma região Azure.
Para uma implementação de nível empresarial, consulte Arquitetura de referência das Máquinas Virtuais do Azure numa zona de destino do Azure.

Detalhes do cenário

O diagrama anterior mostra uma implementação básica de uma única VM numa rede virtual. Este cenário é útil para fornecer uma carga de trabalho não crítica para utilizadores apenas internos.

Potenciais casos de utilização

Esta arquitetura adequa-se a uma aplicação simples que não precisa de exposição pública à internet e pode tolerar interrupções ocasionais. Uma ferramenta básica de relatórios internos é um caso de uso típico.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Esta arquitetura de exemplo utiliza uma única VM, pelo que oferece um nível mínimo de fiabilidade. Qualquer problema com a VM, ou com o host onde está a correr, causa uma falha e torna as cargas de trabalho alojadas indisponíveis. Para qualquer carga de trabalho que exija maior disponibilidade, implemente múltiplas VMs que contenham a mesma carga de trabalho e coloque essas instâncias atrás de uma solução de balanceamento de carga adequada. Se estiverem localizadas na mesma região, implemente essas VMs entre zonas de disponibilidade (onde suportadas) e adicione-as ao backend de um Azure Balanceador de Carga Standard ou de um Application Gateway se a carga de trabalho for baseada em HTTP/HTTPS. Esta arquitetura permite que a carga de trabalho permaneça disponível caso uma única VM no backend avarie.

Os conjuntos de escalas de máquinas virtuais são outra opção para ajudar a simplificar a gestão de cargas de trabalho com múltiplos nós que necessitam da capacidade de escalar automaticamente o número de instâncias de entrada ou saída, dependendo de várias métricas, como o consumo de CPU e memória.

Alta disponibilidade e recuperação de desastres (HA/DR)

Para reduzir o raio de explosão e melhorar a resiliência, posicione a carga de trabalho em várias regiões e utilize a orientação da zona de aterragem Azure. Esta implementação pode estar numa configuração ativo-passivo, com failover para a região secundária caso a região primária fique indisponível, ou numa arquitetura ativo-ativa em que ambas as regiões encaminham tráfego para os consumidores.

Por exemplo, consulte Aplicação Web multicamada concebida para alta disponibilidade e recuperação de desastres. O exemplo desse artigo utiliza o Azure Site Recovery para replicar os discos de VMs individuais para uma região secundária. Pode usar o Site Recovery para fazer failover essas VMs para a região secundária usando um objetivo de baixo ponto de recuperação (RPO) e um objetivo de tempo de recuperação (RTO).

Certifica-te de avaliar a tua arquitetura para cumprir os requisitos de HA/DR em todos os componentes, não apenas nas VMs. Em todas estas decisões, incluem-se considerações como redes, identidade e dados.

Segurança

A segurança oferece proteções contra ataques deliberados e o uso indevido dos seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Considere estes pontos ao desenvolver a sua arquitetura:

Use Microsoft Defender para a Cloud para obter uma visão central do estado de segurança dos seus recursos Azure. O Defender para a Cloud monitoriza potenciais problemas de segurança e fornece uma visão abrangente da saúde da sua implementação. Configure o Defender para a Cloud por subscrição do Azure e ative a recolha de dados de segurança. O Defender para a Cloud analisa automaticamente as VMs criadas sob essa subscrição.
- Gestão de patches: Quando ativado, o Defender para a Cloud identifica a falta de segurança e atualizações críticas.
- Anti-malware: Quando ativado, o Defender para a Cloud verifica se está instalado software anti-malware. Também pode usar o Defender para a Cloud para instalar software anti-malware diretamente a partir do portal Azure.
Use Azure controle de acesso baseado em funções (Azure RBAC) para controlar o acesso aos recursos da Azure. Com o Azure RBAC, concede aos utilizadores apenas as permissões de que precisam para desempenhar o seu trabalho. Por exemplo, o papel Leitor pode visualizar recursos do Azure mas não pode criá-los, gerir ou eliminá-los. Algumas permissões são específicas para um tipo de recurso Azure. Por exemplo, o papel de Contribuidor de Máquina Virtual pode reiniciar ou desalocar uma VM, redefinir a palavra-passe do administrador e criar uma nova VM. Outros papéis incorporados que podem ser úteis para esta arquitetura incluem DevTest Labs User e Network Contributor.

Nota

O Azure RBAC não limita as ações que um utilizador com sessão iniciada numa VM pode realizar. O tipo de conta no sistema operativo convidado determina essas permissões.
Use os registos de auditoria para ver ações de provisionamento e outros eventos da VM.
Ative a encriptação no host para conseguir encriptação de ponta a ponta para os dados da sua VM, incluindo discos temporários e caches de disco. A encriptação no host trata da encriptação na infraestrutura do host da VM e não consome recursos da CPU da VM, ao contrário da encriptação baseada em convidados. Pode usar chaves geridas pelo cliente com Azure Key Vault para sistemas operativos persistentes e discos de dados. Os discos temporários e os discos efémeros do sistema operativo são encriptados com chaves geridas pela plataforma. Verifique se o tamanho da VM selecionado suporta encriptação no host antes de provisionar a VM.

Otimização de Custos

A Otimização de Custos foca-se em encontrar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Há várias opções para tamanhos de VM, dependendo do uso e da carga de trabalho. A gama inclui a opção mais económica da série Bs até às mais recentes VMs de GPU otimizadas para machine learning. Para informações sobre as opções disponíveis, consulte preços das VMs Linux no Azure.

Para cargas de trabalho previsíveis, use o Azure Reservations e o Azure Savings Plan para o cálculo. Um contrato de um ou três anos pode reduzir substancialmente os custos de cálculo em comparação com as tarifas pay-as-you-go. Para cargas de trabalho sem tempo previsível de conclusão ou consumo de recursos, considere a opção Pagar à medida que usa.

As VMs do Azure Spot utilizam capacidade extra do Azure a taxas significativamente reduzidas. O Azure pode despejar VMs Spot com pouco aviso quando precisa de capacidade de volta, por isso só são adequadas para cargas de trabalho tolerantes a falhas sem prazo rigoroso de conclusão. Considere VMs localizadas para:

Cenários de computação de alto desempenho, tarefas de processamento em lotes ou aplicações de composição visual.
Ambientes de teste, incluindo integração contínua e cargas de trabalho de entrega contínua.
Aplicações sem estado de grande escala.

Utilize a calculadora de preços do Azure para prever os custos.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

Utilize modelos de infraestrutura como código (IaC) para aprovisionar recursos do Azure e as suas dependências. Pode escrever estes templates usando o Bicep, Azure Resource Manager ou Terraform. Estes modelos podem ser usados como parte de um pipeline de integração contínua e implantação contínua (CI/CD) através da implantação automatizada. Esta abordagem fornece controlo de versões sobre a sua arquitetura, assegura consistência entre ambientes e impõe reprodutibilidade, segurança e conformidade.

Para ajudar a monitorizar e diagnosticar problemas, ativa os registos de diagnóstico dos teus recursos e envia-os para o Azure Monitor para análise e otimização. Pode usar estes registos para implementar alertas e notificações de eventos críticos e, em alguns casos, permitir a remediação automática ou o registo de tickets no seu sistema de Gestão de Serviços de TI (ITSM).

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.

A eficiência de desempenho ajuda-o a minimizar a latência, alcançar arquiteturas escaláveis, otimizar a utilização de recursos e melhorar continuamente o desempenho do sistema. As decisões que tomas relativamente à arquitetura da carga de trabalho, tamanho da VM e configurações do disco podem afetar muito o desempenho da tua carga de trabalho. Fazer as escolhas certas pode evitar a necessidade de reestruturar a solução no futuro, adicionar flexibilidade e poupar custos.