Executar uma VM do Linux no Azure

Serviço de Backup do Azure
Azure Bastion
Armazenamento do Blobs do Azure
Azure Resource Manager
Armazenamento do Azure
Máquinas Virtuais do Azure

O provisionamento de uma VM (máquina virtual) em Azure requer componentes adicionais além da própria VM, incluindo recursos de rede e armazenamento. Este artigo mostra as práticas recomendadas para executar uma VM segura do Linux em Azure.

Arquitetura

Diagrama que mostra uma VM linux em Azure.

Carrege um arquivo Visio desta arquitetura.

Workflow

Este exemplo mostra uma implantação básica usando uma única máquina virtual com os componentes necessários. A máquina virtual pode executar cargas de trabalho, é gerenciável e pode se comunicar com a Internet pública. Ele foi projetado para evitar a exposição direta a ameaças externas.

  • Todas as cargas de trabalho em execução na máquina virtual não são expostas externamente e só podem ser acessadas de dentro da mesma rede virtual ou emparelhada, como em uma configuração de hub e spoke.
  • O acesso de gerenciamento à máquina virtual é mostrado usando Azure Bastion por meio do Secure Shell (SSH) e não é permitido diretamente da Internet pública.
  • O acesso à Internet externo de saída é fornecido por meio do uso do Gateway de NAT (Conversão de Endereços de Rede) e seu endereço IP público associado.

Componentes

Grupo de recursos

Um grupo resource é um contêiner lógico que contém recursos Azure relacionados. Agrupe os recursos com base em seu tempo de vida e em quem irá gerenciá-los.

Implante recursos intimamente associados que compartilham o mesmo ciclo de vida no mesmo grupo de recursos. Os grupos de recursos permitem implantar e monitorar recursos como um grupo e rastrear custos de cobrança por grupo de recursos. Também é possível excluir recursos como um conjunto, o que é útil para implantações de teste. Atribua nomes de recursos significativos para simplificar a localização de um recurso específico e o reconhecimento de sua função. Para obter mais informações, consulte Recommended Naming Conventions for Azure Resources.

Máquina virtual

Você pode provisionar uma VM a partir de uma lista de imagens publicadas, ou de uma imagem gerenciada personalizada ou a partir de um arquivo VHD (disco rígido virtual) carregado para o Armazenamento de Blobs do Azure. Azure dá suporte à execução de várias distribuições populares do Linux, incluindo Debian, Red Hat Enterprise Linux (RHEL) e Ubuntu. Para obter mais informações, consulte Azure e Linux.

Azure fornece muitos tamanhos de máquina virtual diferentes. Se você mover uma carga de trabalho existente para a Azure, comece com o tamanho da máquina virtual que mais se aproxima dos seus servidores locais. Em seguida, meça o desempenho da carga de trabalho real em termos de CPU, memória e IOPS (operações de entrada/saída de disco por segundo) e ajuste o tamanho conforme a necessidade.

Geralmente, escolha uma região Azure mais próxima de seus usuários ou clientes internos. Nem todos os tamanhos de VM estão disponíveis em todas as regiões. Para obter mais informações, consulte Serviços por região. Para obter uma lista dos tamanhos de VM disponíveis em uma região específica, execute o seguinte comando no CLI do Azure:

az vm list-sizes --location <location>

Para obter informações sobre como escolher uma imagem de VM publicada, consulte Find Linux VM images.

Discos

Para obter o melhor desempenho de E/S de disco, recomendamos SSDs Premium, que armazenam dados em SSDs (unidades de estado sólido). O custo é baseado na capacidade do disco provisionado. O IOPS e a taxa de transferência (ou seja, a taxa de transferência de dados) também dependem do tamanho do disco. Portanto, ao provisionar um disco, considere todos os três fatores (capacidade, IOPS e taxa de transferência). Os SSDs Premium têm uma intermitência gratuita que, combinada com uma compreensão dos padrões de carga de trabalho, oferece uma estratégia eficaz de seleção de SKU e otimização de custos para a infraestrutura de IaaS. Isso permite um alto desempenho sem excesso de provisionamento e minimiza o custo da capacidade não utilizada.

Observação

Atualmente, os discos Premium SSD v2 e Ultra só podem ser usados para discos de dados. Eles não têm suporte para discos do sistema operacional.

Managed Disks simplificam o gerenciamento de discos cuidando do armazenamento para você. Os discos gerenciados não exigem uma conta de armazenamento. Você define o tamanho e o tipo de disco, e ele é implementado como um recurso altamente disponível. Managed disks também oferecem otimização de custo fornecendo o desempenho desejado sem a necessidade de provisionamento excessivo, contabilizando padrões de carga de trabalho flutuantes e minimizando a capacidade provisionada não utilizada.

Por padrão, o disco do sistema operacional é um disco gerenciado armazenado em Armazenamento em Disco do Azure, portanto, ele persiste mesmo quando o computador host está inativo. No caso de cargas de trabalho sem estado, onde se deseja um provisionamento rápido e sem persistência do sistema operacional, são recomendados discos de SO efêmeros. Esses discos colocam a imagem do SO no armazenamento local do host da VM em vez de no armazenamento remoto do Azure, reduzindo a latência de leitura, acelerando a reimagem e eliminando o custo do disco gerenciado. No entanto, todos os dados em um disco do sistema operacional efêmero são perdidos ao parar (desalocar), reimagem ou eventos de recuperação de manutenção do host. Discos de SO efêmeros não dão suporte a instantâneos ou ao Backup do Azure. Use discos do sistema operacional efêmero somente quando as VMs forem totalmente reimplantáveis através de automação.

Muitas imagens do Linux não configuram o espaço de troca por padrão. Se sua carga de trabalho exigir swap, crie-o no disco temporário usando cloud-init em vez de no disco do sistema operacional ou em um disco de dados.

É recomendável criar um ou mais discos de dados para dados do aplicativo. Os discos de dados são discos gerenciados persistentes apoiados por Armazenamento do Azure.

Quando você cria um disco, ele não é formatado. Faça logon na VM para formatar o disco. No shell do Linux, os discos de dados são exibidos como /dev/sdc, /dev/sdde letras posteriores na série. Você pode executar lsblk para listar os dispositivos de bloco, incluindo os discos. Para usar um disco de dados, crie uma partição e o sistema de arquivos 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 você adiciona um disco de dados, uma ID de LUN (número de unidade lógica) é atribuída ao disco. Opcionalmente, você poderá especificar a ID do LUN — por exemplo, se estiver substituindo um disco e quiser manter a mesma ID de LUN ou tiver um aplicativo que está procurando uma ID de LUN específica. No entanto, lembre-se de que as IDs de LUN devem ser exclusivas para cada disco.

Talvez você queira alterar o agendador de E/S para otimizar o desempenho ao usar discos de Armazenamento Premium em SSDs. Uma recomendação comum é usar o agendador No Operation (NOOP) para SSDs, mas você deve usar uma ferramenta como iostat para monitorar o desempenho de disco em E/S para sua carga de trabalho.

Muitas VMs são criadas com um disco temporário, que é armazenado em uma unidade física no computador host. É não salvo em Armazenamento do Azure e pode ser excluído durante reinicializações e outros eventos de ciclo de vida da VM. Use esse disco somente para dados temporários, como arquivos de paginação ou de permuta. Para VMs do Linux, o disco temporário é /dev/disk/azure/resource-part1 e é montado em /mnt/resource ou /mnt.

Rede

Os componentes de rede incluem os seguintes recursos:

  • Rede virtual. Cada VM é implantada em um virtual network que é segmentado em sub-redes.

  • Interface de rede (NIC). A NIC permite que a VM se comunique com o virtual network. Se você precisar de vários NICs para sua VM, um número máximo de NICs é definido para cada tamanho de VM.

  • Endereço IP público. Um endereço IP público pode ser usado para se comunicar com a VM de fora do Azure via SSH. No entanto, isso é desencorajado, pois é um risco potencial à segurança.

    Aviso

    Anexar um endereço IP público representa diretamente um risco potencial de segurança. Isso só deve ser feito em circunstâncias extremas e somente em conjunto com outros métodos de segurança, como filtrar o tráfego usando grupos de segurança de rede.

    Para o acesso de gerenciamento a uma máquina virtual, recomendamos que você use Azure Bastion ou internamente quando conectado por meio de uma VPN ou Azure ExpressRoute.

    • Esse endereço IP público pode ser dinâmico ou estático. O padrão é dinâmico. Reserve um endereço IP stático se precisar de um endereço IP fixo que não seja alterado, por exemplo, se precisar criar um registro DNS 'A' ou adicionar o endereço IP a uma lista segura.
    • Você também pode criar um FQDN (nome de domínio totalmente qualificado) para o endereço IP. Em seguida, é possível registrar um registro CNAME no DNS que aponta para o FQDN. Para obter mais informações, consulte Criar um nome de domínio totalmente qualificado no portal Azure.

  • NSG (grupo de segurança de rede) . Os grupos de segurança de rede são usados para permitir ou negar o tráfego de rede para VMs e/ou sub-redes. Elas podem ser associadas às sub-redes ou a NICs individuais anexadas a VMs.

    • Todos os NSGs contêm um conjunto de regras padrão, incluindo uma regra que bloqueia todo o tráfego de Internet de entrada. As regras padrão não podem ser excluídas, mas outras regras podem substituí-las. Por exemplo, para habilitar o tráfego da Internet, crie regras que permitem o tráfego de entrada para portas específicas, como a porta 443 para HTTPS.

  • Gateway NAT do Azure.Gateways de Tradução de Endereços de Rede (NAT) permitem que todas as instâncias em uma sub-rede privada se conectem à Internet enquanto permanecem totalmente privadas. Somente os pacotes que chegam como pacotes de resposta a uma conexão de saída podem passar por um gateway da NAT. Conexões de entrada não solicitadas da Internet não são permitidas.

    Observação

    Para melhorar a segurança padrão, o acesso implícito à Internet de saída está sendo preterido para todas as novas redes virtuais. A conectividade com a Internet de saída precisará ser configurada explicitamente por meio do uso de outros recursos, como Gateways NAT, Azure Balanceadores de Carga Padrão ou firewalls. Consulte Acesso de saída padrão no Azure para obter detalhes.

  • Azure Bastion.Azure Bastion é uma plataforma totalmente gerenciada como uma solução de serviço que fornece acesso seguro a VMs por meio 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. Azure Bastion fornece conectividade RDP (Protocolo de Área de Trabalho Remota) segura ou SSH para suas VMs diretamente por meio do TLS (Transport Layer Security) por meio de vários métodos, incluindo o portal Azure ou clientes nativos de SSH ou RDP.

Operações

SSH. Antes de criar uma VM do Linux, gere um par de chaves pública-privada do RSA de 2048 bits. Use o arquivo de chave pública ao criar a VM. Para obter mais informações, consulte How to Use SSH with Linux and Mac on Azure.

Diagnóstico. Habilite o monitoramento e diagnóstico, incluindo métricas básicas de integridade, logs de infraestrutura de diagnóstico e diagnósticos de inicialização. O diagnóstico de inicialização poderá ajudar a diagnosticar uma falha de inicialização se sua VM entrar em um estado não inicializável. Crie uma conta Armazenamento do Azure para armazenar os logs. Uma conta de armazenamento padrão com redundância local (LRS) é suficiente para logs de diagnóstico. Para saber mais, confira Habilitar monitoramento e diagnóstico.

Disponibilidade. Sua VM pode ser afetada por manutenção planejada ou por tempo de inatividade não planejado. Você pode usar os logs de reinicialização da VM para determinar se uma reinicialização da VM foi causada por manutenção planejada. Para maior disponibilidade, implante várias VMs entre zonas de disponibilidade em uma região. Isso fornece um SLA (contrato de nível de serviço) mais alto. Quando não há suporte para zonas de disponibilidade, os conjuntos de disponibilidade podem ajudar a fornecer proteção contra falhas de host ou atualizações de host. No entanto, as zonas de disponibilidade são a opção recomendada sempre que possível.

Backups. Para proteger contra perda acidental de dados, use o serviço Backup do Azure para fazer backup de suas VMs no armazenamento. Dependendo da região, você pode usar o armazenamento com redundância geográfica ou com redundância de zona para backups. Backup do Azure fornece backups consistentes com o aplicativo. Para cargas de trabalho sensíveis ao desempenho ou distribuições Linux especializadas que não suportam agentes de backup tradicionais, use o recurso de backup consistente em caso de falha em múltiplos discos sem agente que permite a proteção de backup automatizado sem impactar o desempenho dos aplicativos.

Interromper uma VM. Azure faz uma distinção entre estados "parados" e "desalocados". Você será cobrado quando o status da VM for interrompido, mas não quando a VM for desalocada. No portal Azure, o botão Stop desaloca a VM. No entanto, se você desligar por meio do sistema operacional enquanto estiver conectado, a VM será interrompida, mas não desalocada e, portanto, você ainda será cobrado.

Excluir uma VM. Se você excluir uma VM, terá a opção de excluir ou manter seus discos. Isso significa que você poderá excluir com segurança a VM sem perda de dados. No entanto, você ainda será cobrado pelos discos. Você pode excluir discos gerenciados como qualquer outro recurso de Azure. Para evitar a exclusão acidental, use um resource lock para bloquear todo o grupo de recursos ou bloquear recursos individuais, como uma VM.

Alternatives

  • Conjuntos de dimensionamento de máquinas virtuais – cargas de trabalho críticas para operações de negócios nunca devem depender de uma única máquina virtual. Os conjuntos de dimensionamento fornecem a capacidade de espalhar cargas de trabalho entre os nós e podem escalar para fora em tempos de maior tráfego ou escalar para dentro quando o tráfego é mínimo para ajudar a minimizar os custos.

  • Azure Load Balancer seria útil para fornecer balanceamento de carga entre várias máquinas virtuais ou um conjunto de dimensionamento de máquinas virtuais. Ele também pode ser usado como alternativa a um Gateway de NAT para permitir o acesso a uma carga de trabalho da Internet, ao mesmo tempo em que dá suporte ao acesso de saída.

  • Application Gateway forneceria funcionalidade de balanceamento de carga ao Azure Load Balancer para cargas de trabalho HTTP/HTTPS em uma região Azure.

  • Para uma implantação em nível corporativo, consulte a arquitetura básica de Máquinas Virtuais do Azure em uma zona de hospedagem Azure.

Detalhes do cenário

No diagrama acima, esse cenário seria útil para fornecer uma carga de trabalho não crítica que é útil para usuários somente internos.

Possíveis casos de uso

Uma única implantação de VM pode ser usada para hospedar um aplicativo simples que não precisa ser exposto à Internet e pode suportar algum tempo de inatividade. Por exemplo, esse pode ser um aplicativo de relatório interno básico.

Considerações

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

Fiabilidade

A confiabilidade garante 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.

Como essa arquitetura é apenas um exemplo simples usando uma única máquina virtual, ela tem um nível mínimo de confiabilidade. Qualquer problema com a própria máquina virtual ou o host em que ela está sendo executada causará uma interrupção, resultando em cargas de trabalho hospedadas indisponíveis. Para qualquer carga de trabalho que precise de maior disponibilidade, várias máquinas virtuais devem ser implantadas que contenham a mesma carga de trabalho, com essas instâncias por trás de uma solução de balanceamento de carga apropriada. Se estiverem dentro da mesma região, essas VMs deverão ser implantadas entre zonas de disponibilidade (onde houver suporte) e adicionadas ao back-end de um Azure Standard Load Balancer ou de um Gateway de Aplicativo se a carga de trabalho for baseada em HTTP/HTTPS. Isso permite que a carga de trabalho ainda esteja disponível se uma única máquina virtual no back-end estiver inativa.

Os conjuntos de dimensionamento de máquinas virtuais são outra opção para ajudar a simplificar o gerenciamento de cargas de trabalho de vários nós que precisam da capacidade de dimensionar automaticamente o número de instâncias dentro ou fora, dependendo de qualquer uma das várias métricas, como CPU e/ou consumo de memória.

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

Para um "raio de explosão" reduzido, a carga de trabalho deve ser implantada em várias regiões e aproveitar as diretrizes do Azure Landing Zone. Isso pode estar em uma configuração de Active-Passive, com failover para a região secundária se a região primária ficar indisponível, ou uma arquitetura Active-Active em que ambas as regiões atendem ao tráfego para os consumidores. Para obter um exemplo, consulte o aplicativo Web de várias camadas criado para HA/DR nas Próximas Etapas abaixo.

O exemplo nesse artigo usa Azure Site Recovery para replicar os discos de máquinas virtuais individuais para uma região secundária, onde o Site Recovery pode ser usado para realizar o failover dessas máquinas virtuais para a região secundária com um RPO (Objetivo de Ponto de Recuperação)/RTO (Objetivo de Tempo de Recuperação) baixo.

Avalie sua arquitetura para atender aos requisitos de HA/DR em todos os componentes, não apenas nas máquinas virtuais. Em todas essas decisões, inclua considerações como rede, identidade e dados.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Use Microsoft Defender para Nuvem para obter uma visão central do estado de segurança de seus recursos de Azure. O Defender para Nuvem monitora problemas de segurança potenciais e fornece uma visão abrangente da integridade de segurança de sua implantação. O Defender para Nuvem é configurado por assinatura Azure. Habilite a coleta de dados de segurança, conforme descrito em Conecte suas assinaturas de Azure. Depois que a coleta de dados for habilitada, o Defender para Nuvem examinará automaticamente todas as VMs criadas nessa assinatura.

Gerenciamento de patch. Se for habilitado, o Defender para Nuvem verificará se quaisquer atualizações críticas e de segurança estão ausentes.

Antimalware. Se habilitado, Defender para Nuvem verifica se o software antimalware está instalado. Você também pode usar Defender para Nuvem para instalar software antimalware de dentro do portal Azure.

Controle de acesso. Use Azure controle de acesso baseado em função (Azure RBAC) para controlar o acesso aos recursos do Azure. Azure RBAC permite atribuir funções de autorização a membros da sua equipe do DevOps. Por exemplo, a função Leitor pode exibir Azure recursos, mas não criá-los, gerenciá-los ou excluí-los. Algumas permissões são específicas para um tipo de recurso Azure. Por exemplo, a função Colaborador de Máquina Virtual pode reiniciar ou desalocar uma VM, redefinir a senha de administrador e criar uma nova VM. Outras funções internas que podem ser úteis para essa arquitetura incluem Usuário do DevTest Labs e Colaborador de Rede.

Observação

Azure RBAC não limita as ações que um usuário conectado a uma VM pode executar. Essas permissões são determinadas pelo tipo de conta no SO convidado.

Logs de auditoria. Use audit logs para ver ações de provisionamento e outros eventos de VM.

Criptografia de dados. Habilite encriptação no host para oferecer criptografia de ponta a ponta para seus dados de VM, incluindo discos temporários e caches de disco. A criptografia no host manipula a criptografia na infraestrutura de host da VM e não consome recursos de CPU de VM, ao contrário da criptografia baseada em convidado. Você pode usar chaves gerenciadas por customer com Azure Key Vault para discos de dados e sistema operacional persistentes. Discos temporários e discos de sistema operacional efêmeros são criptografados com chaves gerenciadas pela plataforma. Verifique se o tamanho VM selecionado dá suporte à criptografia no host antes de provisionar a VM.

Otimização de custos

A Otimização de Custos trata-se de procurar maneiras 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 design para otimização de custos.

Há várias opções para tamanhos de VM, dependendo do uso e da carga de trabalho. O intervalo inclui a opção mais econômica da série Bs para as VMs de GPU mais recentes otimizadas para machine learning. ** Para obter informações sobre as opções disponíveis, consulte Preços de Azure VM Linux.

Para cargas de trabalho previsíveis, use Azure Reservations e Plano de economia do Azure para computação com um contrato de um ou três anos e receba descontos significativos nos preços de pagamento conforme o uso. Para cargas de trabalho sem tempo previsível de conclusão ou consumo de recursos, considere a opção Pagamento conforme o uso.

Use Azure Spot VMs para executar cargas de trabalho que podem ser interrompidas e não exigem conclusão dentro de um período predeterminado ou de um SLA. Azure implanta VMs spot se houver capacidade disponível e as revoga quando precisar da capacidade de volta. Os custos associados ao Spot virtual machines são significativamente menores. Considere as VMs Spot para estas cargas de trabalho:

  • Cenários de computação de alto desempenho, processamento em lotes ou aplicativos de renderização visual.
  • Ambientes de teste, incluindo cargas de trabalho de integração contínua e entrega contínua.
  • Aplicativos sem estado de grande escala.

Use a calculadora de preços Azure para estimar os custos.

Para obter mais informações, consulte a seção de custo no Microsoft Azure Well-Architected Framework.

Excelência Operacional

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

Use modelos de IaC (Infraestrutura como Código) para provisionar Azure recursos e suas dependências. Eles podem ser escritos usando modelos do ARM Bicep, Azure Resource Manager (modelos arm) ou Terraform, dependendo de sua preferência e escolhas de ferramentas estabelecidas. Esses modelos permitem um processo de CI/CD (Integração Contínua/Implantação Contínua) como parte de uma metodologia de implantação automatizada para implantar e configurar recursos. Essa abordagem permite o controle de versão de arquiteturas e garante a consistência entre ambientes, bem como a imposição de reprodutibilidade, segurança e conformidade.

Para ajudar no monitoramento e diagnóstico de problemas, verifique se os logs de diagnóstico estão habilitados em seus recursos e são disponibilizados para Azure Monitor para ajudar na análise e otimização de seus recursos. Esses logs podem ser usados para implementar alertas e notificações de eventos críticos e, em alguns casos, permitem a correção automatizada ou o registro em log de um tíquete no sistema ITSM (Gerenciamento de Serviços de TI).

Eficiência de desempenho

A Eficiência de Desempenho concentra-se na otimização de cargas de trabalho de nuvem para velocidade, capacidade de resposta e escalabilidade. Para obter mais informações, consulte a lista de verificação de revisão de design para Eficiência de Desempenho.

Algumas das principais metas incluem minimizar a latência, garantir arquiteturas escalonáveis, otimizar a utilização de recursos e melhorar continuamente o desempenho do sistema.

Conforme mencionado acima, as decisões tomadas em relação à arquitetura da carga de trabalho, ao SKU da VM e às configurações de disco podem ter um grande impacto sobre o desempenho da carga de trabalho. Fazer as escolhas corretas pode impedir a necessidade de arquitetar novamente a solução no futuro, adicionando flexibilidade e economizando custos.

Considere estes pontos ao desenvolver sua arquitetura:

  • Use conjuntos de dimensionamento de máquinas virtuais se a carga de trabalho tiver uma carga dinâmica. Por exemplo, escale horizontalmente em tempos de grandes quantidades de tráfego e, em seguida, desescale horizontalmente quando o tráfego diminuir. Isso garantirá o poder de processamento adequado enquanto ainda mantém os custos sob controle.
  • Escolha as SKUs de disco e VM apropriadas para atender ao IOPS necessário durante o processamento. Configure o cache para melhorar ainda mais o desempenho.
  • Se sua carga de trabalho for sensível a latência incomum, utilize Grupos de Posicionamento por Proximidade (PPGs) para garantir que várias VMs estejam fisicamente próximas para obter um melhor desempenho. Os PPGs também podem ser usados em conjunto com conjuntos de disponibilidade para combinar baixa latência com alta disponibilidade em um único datacenter físico.
  • Sempre que possível, habilite a rede acelerada para minimizar a latência entre os componentes.
  • Criar arquitetura de rede para minimizar saltos desnecessários.
  • Use Azure Monitor, VM Insights e outras ferramentas para analisar continuamente as métricas e criar linhas de base de desempenho atualizadas. Use as informações de desempenho para determinar onde implementar alterações e, em seguida, testar essas linhas de base.

Contributors

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Próximas etapas